Data transferring method

ABSTRACT

A method of transferring data is provided. The method of transferring data in a data interoperable environment includes: receiving a data transmission request message for requesting the data to be transmitted from a client to at least one destination; gathering information on entities which are to participate in the transmission of the data; and forming a plurality of chains including at least two entities based on the gathered information on the entities and transmitting the data to the at least one destination through the plurality of chains. Accordingly, it is possible to effectively transmit data using multi-chains in a DRM interoperable environment.

This application is a § 371 of PCT/KR2007/001115, filed Mar. 6, 2007,and claims the benefit of U.S. Provisional App. Nos. 60/778,928, filedMar. 6, 2006; 60/743,417, filed Mar. 7, 2006; 60/744,322, filed Apr. 5,2006; 60/744,811, filed Apr. 13, 2006; 60/799,411, filed May 9, 2006;60/802,943, filed May 23, 2006; 60/803,834, filed Jun. 2, 2006;60/814,977, filed Jun. 19, 2006; 60/832,514, filed Jul. 20, 2006;60/824,700, filed Sep. 6, 2006; 60/862,684, filed Oct. 24, 2006;60/862,808, filed Oct. 25, 2006; and 60/865,520, filed Nov. 13, 2006,each of which are incorporated herein by reference.

TECHNICAL FIELD

The present invention relates to a method of transferring data, and moreparticularly, to a method of effectively transmitting data by usingmulti-chains in a DRM interoperable environment.

BACKGROUND ART

In general, unlike an analogue content, since a digital content can beunlimitedly copied without a loss of information, the digital contentcan be easily exposed to illegal copy and use. This is why a contentprotection technique capable of stably protecting a digital contentagainst illegal copy and use has to be supported in order to provide adigital content service.

A digital rights management (DRM) is a total digital content protectiontechnique capable of allowing only a legally authorized user to use adigital content. Although the DRM technically includes a securitytechnique, a watermarking technique, a tamper resistance technique, andthe like, more accurately, the DRM indicates a framework rather thantechnologies.

The DRM focuses on radically preventing illegal copy and use of acontent. In the DRM, a digital content is transformed into encrypteddata in a package form by using an encryption technique. Accordingly,although the digital content is casually obtained by a predetermineduser, the digital content cannot be used without a legal authenticationprocess.

Most legal content services provided through a wired/wirelesscommunication network such as the Internet or mobile communicationnetwork can be executed only by DRM devices which support a DRM employedby a service provider or content provider of the corresponding content.This is due to technical and political closure properties of the DRM.

On the other hand, the technical and political closure properties of theDRM are advantageous in that the legality of the content is secured.However, there is a problem that it is limited for a user to use thecontent. This is because DRM device or DRM-using software in which a DRMemployed by the service provider is installed has to be separatelyincluded, so that a user may use a digital content provided by aplurality of service provider. In this case, the user has to separatelymake a contract, a payment, an authentication, and the like.

The aforementioned problem deteriorates flexibility of a distributionstructure of digital contents. Finally, the problem causes limitation ofdigital content services.

Recently, it is intended to provide a framework in which the closed DRMstructures are compatible with one another. In order to allow differenttypes of DRMs to be compatible with one another, there is required a DRMinteroperable system which mediates the difference among the closedDRMs. The DRM interoperable system can be embodied by defining systemresources and suggesting operation models which generate and manage thedefined system resources. In addition, in order to support the DRMinteroperable system, various scenarios using defined system resourcesand operation models have to be suggested.

DISCLOSURE OF INVENTION Technical Problem

The present invention provides a method of transferring data and amethod of transferring contents capable of effectively transmitting datarequested by a client to a destination through multi-chains.

Technical Solution

According to an aspect of the present invention, there is provided amethod of transferring data in a data interoperable environment, themethod comprising: receiving a data transmission request message forrequesting the data to be transmitted from a client to at least onedestination; gathering information on entities which are to participatein the transmission of the data; and forming a plurality of chainsincluding at least two entities based on the gathered information on theentities and transmitting the data to the at least one destinationthrough the plurality of chains. At this time, the data may be a contentor license.

In the above aspect of the present invention, the gathering of theinformation on the entities which are to participate in the transmissionof the data may comprise: querying the entities about the information onthe entities including capability information; receiving the informationon the entities received in response to the query; and recognizing atleast one piece of information on sources, midway and destinationdevices, systems, and DRMs by using the received information on theentities.

In addition, the at least two entities may comprise: an exporter whichexports the data from a source and transmits the exported data; atransformer which transforms the data transmitted from the exporter intodata with a format requested by a destination and transmits thetransformed data; and an importer which receives the data transmittedfrom the transformer and provides the received data to the destination.Alternatively, the at least two entities may comprise: an exporter whichexports the data from a source and transmits the exported data; and animporter which receives the plurality of data transmitted from theexporter and provides the received data to the destination.

In addition, the transmitting of the data may comprise: forming aprimary chain including an exporter and a transformer and transmittingthe data from the exporter to the transformer through the primary chain;and forming at least one secondary chain including the transformer andan importer and transmitting the data from the transformer to theimporter through the at least one secondary chain.

In addition, the at least two entities included in the plurality ofchains may support a multi-transmission protocol which enables aplurality of data to be transmitted through a single session. Inaddition, a secure authenticated channel may be established among the atleast two entities included in each chain.

In addition, the method of transmitting data may further comprisereceiving an event message for representing at least one of transmissionand transformation statuses of the data transmitted from an entityincluded in a chain through the chain. In this case, the method oftransmitting data may further comprise providing informationcorresponding to the received event message to the client.

In addition, the event message may include at least one among an eventmessage for representing that the data starts to be transmitted, andevent message for representing that the data is being transmitted, anevent message for representing that the transmission of the data iscompleted, and an event message for representing that an error occurs.

According to another aspect of the present invention, there is provideda method of transferring contents in a DRM interoperable system, themethod comprising: receiving a content transmission request messageincluding a plurality of transmission session identifiers from a client;determining a plurality of content handlers which are to participate inthe transmission of the contents by gathering information on contenthandlers; forming a plurality of chains including two or more of thedetermined content handlers in correspondence with the plurality oftransmission session identifiers; and transmitting the contents to atleast one destination through the formed plurality of chains. At thistime, at least one of the two or more content handlers included in eachchain may provide an event message for representing a transmissionstatus of the contents transmitted through the chain.

According to another aspect of the present invention, there is provideda method of transferring contents to a predetermined number ofdestinations in a DRM interoperable system, the method comprising:forming a primary chain including an exporter and a transformer andtransmitting the contents exported by the exporter to the transformerthrough the primary chain; transforming the contents transmitted to thetransformer into contents with a format requested by the destination;and forming a predetermined number of secondary chains including thetransformer and an importer in correspondence with the predeterminednumber of destinations and transmitting the contents transformed by thetransformer to the importer through the formed pre-determined number ofsecondary chains.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other features and advantages of the present inventionwill become more apparent by describing in detail exemplary embodimentsthereof with reference to the attached drawings in which:

FIG. 1 is a block diagram illustrating a concept and main functions of aDRM interoperable system according to an exemplary embodiment of thepresent invention;

FIG. 2 is a block diagram illustrating a schematic structure of a DRMinteroperable system according to an exemplary embodiment of the presentinvention;

FIG. 3 illustrates an example in which a client requests a processingcontrol part to transmit a content;

FIG. 4 illustrates an example in which a client requests a processingcontrol part to transmit a license;

FIG. 5 is a block diagram illustrating a domain, entities whichconstitute a domain, and correlation among the entities;

FIG. 6 illustrates an example of a format of a DPDU data packet neededfor selecting a reference point controller;

FIG. 7 is a flowchart illustrating procedures of automatically selectinga reference point controller by using the DPDU;

FIG. 8 is a flowchart illustrating a method of selecting a referencepoint controller according to Example 1-2;

FIG. 9 is a flowchart illustrating a procedure of selecting a referencepoint controller candidate according to Example 2-1;

FIG. 10 is a block diagram illustrating a reference point controller andconnections among reference point controller candidates for transmittingan information signal;

FIG. 11 is a block diagram illustrating an example in which a typicaldomain device and typical domain candidate devices transmit aninformation signal;

FIG. 12 is a block diagram illustrating a concept of a reference pointcontroller proxy;

FIG. 13 is a flowchart illustrating a procedure of registering areference point controller;

FIG. 14 illustrates an example of a structure for managing uniqueinformation of a legacy device;

FIG. 15 is a flowchart illustrating a procedure of authenticating alegacy device;

FIG. 16 illustrates an example of a structure of a DRM interoperablesystem for managing information on a user who uses a legacy device;

FIG. 17 is a flowchart illustrating a procedure of registering a legacydevice to a domain;

FIG. 18 is a block diagram illustrating structures of a processingcontrol part and a content processing part;

FIG. 19 shows an example for illustrating locations of a contentprocessing controller and content handlers;

FIG. 20 shows an example for illustrating other locations of a contentprocessing controller and content handlers;

FIG. 21 is a flowchart illustrating a procedure of transmitting acontent by using a content processing controller and content handlers;

FIG. 22 shows an example for illustrating a multi-transmission protocol;

FIG. 23 is a block diagram illustrating a structure of a system for acontent transmission procedure according to Example 3-2;

FIG. 24 is a flowchart illustrating the content transmission procedureaccording to Example 3-2;

FIG. 25 illustrates a primary content transformation chain fortransmitting one or more contents to a first destination device;

FIG. 26 illustrates a secondary content transformation chain fortransmitting one or more contents to a second destination device;

FIG. 27 is a block diagram illustrating a structure of a system for acontent transmission procedure according to Example 3-3;

FIG. 28 is a flowchart illustrating the content transmission procedureaccording to Example 3-3;

FIG. 29 shows an example of a primary content transformation chainconstructed with a content processing controller;

FIG. 30 shows an example of a secondary content transformation chainconstructed with a content processing controller;

FIG. 31 is a block diagram illustrating a system for transmitting acontent according to Example 3-4;

FIG. 32 is a flowchart illustrating a content transmission procedureaccording to Example 3-4;

FIG. 33 illustrates an example of a primary content transformation chainconstructed with a content processing controller;

FIG. 34 illustrates an example of structures of a first secondarycontent transformation chain, a second secondary content transformationchain, and a third secondary content transformation chain induced by acontent processing controller;

FIG. 35 is a block diagram illustrating a structure of a system relatedto a transmission of a license;

FIG. 36 shows an example for illustrating unit function modules includedin an entity and functions of the unit function modules;

FIG. 37 shows an example for illustrating a procedure of transmitting anevent between two authenticated entities;

FIG. 38 is a flowchart illustrating a method of managing a domainaccording to Example 4-1;

FIG. 39 is a flowchart illustrating a method of managing a domainaccording to Example 4-2;

FIG. 40 is a block diagram illustrating a structure of a system of anenvironment in which different types of DRMs are compatible with eachother;

FIG. 41 is a block diagram illustrating a detailed structure of a DRMarea;

FIG. 42 is a block diagram illustrating a structure of a DRMinteroperable system;

FIG. 43 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-1;

FIG. 44 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-2;

FIG. 45 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-3;

FIG. 46 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-4;

FIG. 47 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-5;

FIG. 48 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-6; and

FIG. 49 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-7.

REFERENCE NUMERALS

-   -   10: client part    -   20: authentication and management part    -   30: license processing part    -   40: processing control part    -   41: content processing controller    -   50: content processing part    -   51: content transformer    -   52: content exporter    -   53: content importer

BEST MODE FOR CARRYING OUT THE INVENTION

Now, preferred embodiments of the present invention will be described indetail with reference to the attached drawings. In addition, in order toclearly describe exemplary embodiments with reference to theaccompanying drawings, specific technical terms are used. However, thepresent invention is not limited to the selected specific technicalterms, and each specific technical term includes all the technicalsynonyms which operate in a similar manner so as to achieve a similarentity.

FIG. 1 is a block diagram illustrating a concept and main functions of aDRM interoperable system according to an exemplary embodiment of thepresent invention.

As shown in FIG. 1, a DRM interoperable system 1000 serves to allowservices to be compatible with one another between different DRM areas.The DRM interoperable system 1000 can perform a data interoperabilitycontrol function f1, a data interoperability function f2, a statusdisplay function f3, a domain management function f4, and the like.

The data interoperability control function f1 serves to controlinteroperability of data so that data are compatible with one another.At this time, the data may represent a content or license. Specifically,the data interoperability control function f1 includes a contentinteroperability control function f1 a and a license interoperabilitycontrol function f2 b.

The data interoperability function f2 may represent a function ofallowing a content or license to be compatible under a control of thedata interoperability control function f1. For example, according to thedata interoperability function f2, data of a system A or device A in aDRM area A, for example, a content or license can be provided to asystem B or device B in a DRM area B. A content or license of the systemB or device B in the DRM area B can be provided to the system A ordevice A in the DRM area A. Specifically, the data interoperabilityfunction f2 may include a content interoperability function f2 a and alicense interoperability function f2 b.

The status display function f3 may represent a function of displayingoperation statuses of the DRM interoperable system 100. For example, thestatus display function f3 may include event functions such as a channelforming event function f3 a, a transmission related event function f3 b,a transformation related event function f3 c, and the like.

The domain management function f4 may represent a function of managing adomain for authenticating and managing a client. The domain managementfunction f4 may include a reference point controllerregistration/management function f4 a, a legacy device managementfunction f4 b, and the like.

Hereinafter, a structure and an operation of a system for performing theaforementioned functions will be described in detail.

*Structure and Operation of a System*

FIG. 2 is a block diagram illustrating a schematic structure of a DRMinteroperable system in which different types of DRMs are compatiblewith each other.

As shown in FIG. 2, the DRM interoperable system may include a clientpart 10, an authentication and management part 20, a processing controlpart 40, a content processing part 50, and a license processing part 30.

The aforementioned parts may be constructed with one or more entities.At this time, the entities may indicate modules or devices constructedas software or hardware which perform predetermined unique functions.Each entity may be a set of one or more unit function modules whichperforms predetermined unit functions. The entity is installed in apredetermined device to communicate data with another entity through apredetermined interface. In addition, even though the entities belong tothe same part, the entity may be installed or embodied in differentdevices. The devices may be different depending on executionenvironments.

Hereinafter, functions of the entities included each part and operationsthrough interactions among the entities will be described and acharacteristic structure and functions of each part will be described.

1. Function and Operation of the Client Part

The client part 10 may include a client. The client is an entity whichprovides various functions so that a user can use a DRM interoperableservice in linkage with the authentication and management part 20 and aprocessing control part 40.

The client may be included in a device of a user. A device that includesthe client is referred to as a client device.

The client may be authenticated by requesting the authentication andmanagement part 20 to authenticate the client. The authenticated clientmay request the processing control part 40 to transmit predetermineddata, for example, a predetermined content or license to a desireddestination by calling a predetermined entity. Here, the destination maybe a device or software system in which a DRM that is different from theDRM applied to the predetermined content or license is installed, forexample, another client device in the domain.

FIGS. 3 and 4 illustrate examples in which an authenticated clientrequests the processing control part 40 to transmit data. FIG. 3illustrates an example in which the client requests the processingcontrol part 40 to transmit a content. FIG. 4 illustrates an example inwhich the client requests the processing control part 40 to transmit alicense.

As described in FIG. 3, the client requests the content processingcontroller 41 of the processing control part 40 to transmit a content.Then, the content processing controller 41 controls the contentprocessing part 50 so that the requested content is transmitted to thedesired destination. At this time, the content format and the DRM of therequested content may be different from a content format and a DRMrequired by the destination. The content processing part 50 processesthe content so that the content satisfies conditions required by thedestination and provides the processed content to the destination. Thetransmission and processing procedures will be described later withreference to FIGS. 18 to 34.

In addition, as shown in FIG. 4, the client requests a licenseprocessing controller 42 of the processing control part 40 to transmit alicense. Then the license processing controller 42 controls the licenseprocessing part 30 so that the requested license is transmitted to thedesired destination. At this time, a format of the requested license maybe different from that of a license required by the destination. Thelicense processing part 30 processes the different properties so thatconditions required by the destination are satisfied and provides theprocessing result to the destination. The procedures of processing andtransmitting the license will be described later with reference to FIG.35.

On the other hand, the client may include typical functions of theclient, for example, a function of using (or reproducing) a content, auser interface function, and the like. In this case, the client may bean end point of consumption of a content.

The client has to be authenticated as a legal client and managed by theauthentication and management part 20. In order to easily perform theaforementioned process, the DRM interoperable system can introduce aconcept of a domain.

The domain is a basic unit of a DRM trust framework and indicates arange to which the DRM interoperable system is practically applied. Thedomain may be constructed with a set of authorized devices or systems.For example, the domain may include a set of authorized client devices.In this case, although the client devices in the domain includedifferent DRM contents, the client devices may share the contents.

2. Function and Operation of the Authentication and Management Part

FIG. 5 is a block diagram illustrating a domain, entities whichconstitute a domain, and correlation among the entities. FIG. 5illustrates entities related to authentication and management of aclient.

Referring to FIG. 5, the DRM interoperable system forms a domain 5. Thedomain 5 may be constructed in consideration of a physical location of aclient device 12. Specifically, the domain 5 is constructed withauthorized client devices 3 in a pre-determined physical area.Alternatively, the domain 5 may be constructed with only logicallyauthenticated client devices without considering a physical location ofthe client device 12.

In the present invention, as described above, although the domain isconstructed with the client devices 3 in the predetermined local area inconsideration of the physical locations of the client devices 3, a casein which client devices out of the pre-determined local area in anetwork area also subscribe to the domain is exemplified. However, thisis an example of an embodiment. The present invention is not limitedthereto.

A local environment is required so as to construct the domain 5. At thistime, the local environment indicates an environment in which a physicalnetwork is prepared so that devices in a predetermined local area areinteractive with one another, and in which the physical network isinteractive with an external network.

There is a home network system as an example for providing the localenvironment. Generally, in the home network system, home appliances,various sensors, security devices, and the like in a home can beinteractive with one another through a wired/wireless local network andcan be interactive with an external network such as the Internet througha communication node such as a home gateway. The local environment canbe constructed with two or more interactive network devices in additionto the home network system.

The following local area is assumed to be an area in which theaforementioned local environment is prepared. In the local area, theremay exist a plurality of client devices 3. A client 3 included in theclient device 12 can be authenticated as a legal client by requestingthe authentication and management part 20 to authenticate the client 3.A device including the authenticated client 3 is the client device 12.Different DRM contents can be used among the client devices 3 in a rangepermitted by a license.

Accordingly, the user sets the user's house to a local area andconstructs a domain by using devices including different DRMs in thehouse. Then, contents are shared and used among the devices.

However, the client in the external network area can be also providedwith a service through authentication, in addition to the clients 12 inthe local area. In this case, it is necessary to distinguish the statusof the client that is authenticated in the network from the status ofthe client 3 that is authenticated in the local area and to separatelymanage the statuses. For this, the statuses of the authenticated clientscan be classified into a remote status and a local status and can bemanaged.

Referring FIG. 5, the authentication and management part 20 forauthenticating and managing the client 3 include a domain manager 22, alicense manager 24, and a reference point controller 26.

The domain manager 22 is designed to supervise the domain 5. Forexample, the domain manager 22 can perform functions of creating thedomain 5, destroying the domain 5, associating clients with the domain5, removing clients from the domain 5, registering the reference pointcontroller 26, and the like.

The domain manager 22 may exist at any location in the local area ornetwork area. For example, in the example shown in FIG. 5, the domainmanager 22 is located in the network area. In this case, the domainmanager 22 can interact with the reference point controller 26 and theclient 3. Alternatively, the domain manager may be located in the localarea. In this case, the domain manager is included in a device in alocal area to interact with the reference point controller and theclient.

The license manager 24 is designed to manage license information of theuser. For example, the license manager 24 can provide a login functionfor a user and perform a function of a typical online service managerwhich stores and manages the license information. The license manager 24can perform functions of creating user names, deleting user names,associating license information with user names, creating licenseinformation, deleting license information, and the like.

The license manager 24 may be located in a network area, for example aserver of the service provider. However, the license manager 24 may belocated in the network area such as the server of the service provider.Alternatively the license manager 24 may be in the local area. That is,the domain manager 22 and the license manager 24 may be located in anylocation in the local area or network area.

The reference point controller 26 checks whether a predetermined entityis located in the local area and provides a credential which verifiesthat the entity is located in the local area to the verified entity. Forthis, the reference point controller 26 can determine a range of thelocal area. At this time, the range of the local area can be determinedby using a physical distance, the number of hops, a reaction time, andthe like.

The reference point controller 26 checks whether the client 3 is locatedin the local area according to the request of the client 3. When it isdetermined that the client 3 is located in the local area, the referencepoint controller 26 can provide a domain credential which verifies thatthe client 3 is located in the local area. The domain credential can beprovided to the domain manager 22 when the client 3 requests the domainmanager 22 to authenticate the client 3. The domain manager 22 confirmsthat the client 3 is located in the local are and authenticates theclient 3.

In addition, the domain manager 22 determines whether the client 3 is ina remote or local status based on the domain credential. The domainmanager 22 may limit the number of the clients which access the domainmanager 22 in the remote status by recognizing the status of the client3, in order to prevent a plurality of clients to access the domainthrough the network and to improve security.

The reference point controller 26 may be located in the local area.Specifically, the reference point controller 26 may be determined as adevice located in the local area. Although it is advantageous that thereference point controller 26 is determined as a device such as aset-top box, a desktop PC, and the like which includes a plurality ofcomputing resources and have no movability, the reference pointcontroller 26 may be determined as a highly movable device.

The reference point controller 26 can be selected according to apredetermined procedure, when the domain is initially constructed.Specifically, when the domain 5 is initially constructed, a device forperforming a function of the reference point controller for determiningthe range of the local area is selected. The selected device has to bedetermined as the reference point controller 26. At this time, thedetermined reference point controller 26 is registered with the domainmanager 22. Then, the client 3 can query the domain manager 22 about thereference point controller 26.

—Selection of a Reference Point Controller—

There are three methods of selecting a reference point controller.

There is a first method in which the devices that desire to subscribe tothe domain communicate device information with one another and comparethe device information according to a predetermined algorithm, so thatthe most suitable device is selected as the reference point controller.The selected reference point controller has to report to the domainmanager that the device is selected as the reference point controller.Then, the device has to be registered with the domain.

There is a second method in which devices that desire to be registeredwith the domain report device information of the devices to the domainmanager, and the domain management entity selects the reference pointcontroller based on the reported device information.

There is a third method in which a reference point controller isselected by pre-determined information. At this time, the predeterminedinformation may be set by an administrator or user. Alternatively, thepredetermined information may include arbitrarily determinedinformation. For example, when the administrator or user inputs thepredetermined information into the domain manager, the domain managercan select the reference point controller based on the predeterminedinformation. Alternatively, the reference point controller may beestablished by allowing the administrator or user to directly select thedevice to be used as the reference point controller.

Hereinafter, the aforementioned three methods will be described indetail. For convenience of understanding, the aforementioned firstmethod of selecting a reference point controller is referred to asExample 1-1. The second method of selecting a reference point controlleris referred to as Example 1-2. The third method of selecting a referencepoint controller is referred to as Example 1-3.

EXAMPLE 1-1

First, a data format of a domain payload data unit (DPDU) is definedbefore the procedure of selecting a reference point controller isdescribed. The DPDU is a normalized data format for transmitting deviceinformation of each device, when the reference point is selected.

FIG. 6 illustrates an example of a format of a DPDU data packet neededfor selecting a reference point controller.

Referring to FIG. 6, the DPDU is constructed with a domain header and adomain payload.

The domain header includes a device capability identifier (hereinafter,abbreviated to DC-ID), a domain identifier (hereinafter, abbreviated toD-ID), and a device entity identifier (hereinafter, abbreviated toDE-ID).

The DC-ID is information used to identify a capability value of adevice. At this time, the capability value may be information fordisplaying capability of a device with respect to a predetermined item,for example, a residual energy amount, a hardware specification, anetwork connection speed, a networking capability, mobility to outside,stability of a system, a computing power, a resource consumption amount,and the like. An arbitrary value may be allocated to the DC-ID accordingto a predetermined standard determined by the administrator or may begenerated by the corresponding device, before or after the device entersthe domain. The DC-ID is a standard for selecting the most suitabledevice, when the reference point controller is selected.

The D-ID is information used for classifying domains according toenvironments and properties of the devices. As described above, thedomain may be an area classified according to a physical areasclassification standard or may be an area classified through a logicalauthentication service. Accordingly, the D-ID is information whichclassifies domains according to physical areas or is information whichclassifies domains according to logical services.

The DE-ID is information used for identifying separate devices belongingto a domain.

On the other hand, the domain payload is a field for recording generaldata and error checking information. At this time, the general dataindicates information on a device and a DRM reliability system. Inaddition, the error checking information may indicate information forchecking an error of a DPDU packet.

As described above, the DPDU includes information for distinguishingcapabilities of devices subscribed to the domain from one another.Accordingly, the DPDUs are exchanged among the devices in the domain,and the capabilities are compared with one another. Accordingly, acapable device can be selected, and the capable device can be determinedas the reference point controller. Hereinafter, the aforementionedprocesses will be described in detail.

FIG. 7 is a flowchart illustrating procedures of automatically selectinga reference point controller by using the DPDU.

Referring to FIG. 7, when the procedure starts, devices (for example,client devices) to subscribe to a domain set DC-ID values X, D-ID valuesY, and DE-ID values Z to predetermined values (operation S1).

At this time, the DC-ID set values are allocated according to apredetermined standard or are generated in the corresponding devices.The two cases will be separately described in the following.

1. A Case where the DC-ID Values are Allocated by the AdministratorAccording to the Predetermined Standard

The administrator recognizes the capability information of each deviceby using a predetermined management device, transforms the capabilityinformation into the capability value according to the predeterminedstandard, and allocates the capability value to the DC-ID value of thedevice. At this time, the management device may be a predetermineddevice in the domain, a device located at another communicable location,or a predetermined system in a network area (for example, a domainmanager).

For example, when the DC-ID value is determined based on the residualenergy amount, the administrator checks the battery residual amount ofeach device in the domain, the battery residual amount is represented asnumbers according to a pre-determined standard, and the DC-ID values areallocated to the devices. Then, the DC-ID values of the devices aredetermined, that is, the DC-ID of the device A is 4, the DC-ID of thedevice B is 8, and the DC-ID of the device C is 2.

2. A Case where the DC-ID Values are Generated Through the CorrespondingDevices

Each device recognizes the capability information, the capabilityinformation is transformed into the capability value according topreviously stored information, and the capability is set to the DC-IDvalue.

For example, when the DC-ID value is determined based on the energyresidual amount, the device checks the battery residual amount, and thebattery residual amount is represented as numbers according to apreviously stored battery residual amount-energy residual amount mappingtable, and the DC-ID values are generated. Then, the DC-ID values of thedevices are determined, that is, the DC-ID value of the device A is 4,the DC-ID of the device B is 8, and the DC-ID of the device C is 2. Atthis time, the battery residual amount-energy residual amount mappingtable may be received from a management device and stored.Alternatively, the battery residual amount-energy residual amountmapping table may be stored, when a product is manufactured.

In Example 1-1, it is assumed that as the battery capacity is high, theDC-ID value is set to be small. In this case, as the DC-ID value becomessmall, the device has a high capability. However, the present inventionis not limited thereto. Alternatively, it may be assumed that as thebattery capacity is small, the DC-ID value is set to be small.

In addition, the capability ability of the device may be constructedwith hardware specifications, a network connection speed, a networkingcapability, mobility to outside, stability of a system, a computingpower, a resource consumption amount, and the like, in addition to theenergy residual amount. The DC-ID value may be not a simple number butvarious types of information.

On the other hand, the D-ID is set as a unique number or informationdata for displaying a domain to which a device subscribes. In addition,the DE-ID value of each device is initialized as codes fordistinguishing the devices from one another. The D-ID value and theDE-ID value may be allocated by the administrator or may be generated bythe corresponding device.

As described above, when setting the DC-ID and the D-ID is completed foreach device, the device sequentially broadcasts or multicasts the DPDUincluding the set information to neighboring devices (operation S2).

Then, the device can receive the DPDU transmitted from another device(operation S3). When a predetermined device receives the DPDU, thecorresponding device extracts the DC-ID value V included in a domainheader of the received DPDU (operation S4) and compares the extractedDC-ID value with the DC-ID value X of the device (operation S5). On theother hand, when the DPDU is not received, it is determined whether theset time T1 is elapsed (operation S12). V represents the DC-ID value ofthe DPDU which is received from another device. In the device whichtransmits the DPDU, the DC-ID value may be X.

As the comparison result of the DC-ID value, when the DC-ID value of thedevice is less than the received DC-ID value, the device destroys thereceived DC-ID value (operation S6). In this case, this is because thedevice that receives the DC-ID has a higher energy capacity, which isthe capability, than the device that transmits the DC-ID.

On the other hand, as the comparison result of DC-ID value, when theDC-ID value of itself is greater than the received DC-ID value, thedevice extracts the D-ID information W included in the domain header ofthe received DPDU (operation S7) and checks whether the extracted D-IDinformation W is the same as the D-ID information Y of itself (operationS8). The reference point controller can be selected one by one in thesame domain by checking the received D-ID information. W represents theD-ID value of DPDU which is received from another device. In the devicewhich transmits the DPDU, the DC-ID value may be Y.

As the checking result of D-ID, when the received D-ID is the same asthe D-ID of the device, the device stops broadcasting of the DPDU(operation S9). This is because a device which has a high capacity valueis located in the same domain. This may represent that the device failsin the selection of the reference point controller.

On the other hand, as the checking result of the D-ID, when the receivedD-ID is different from the d-ID of the device, the device considers thereceived DPDU as the DPDU received from a device in another domain andsuccessively broadcasts the DPDU. At this time, the device transmits theDPDU to another device and checks whether the set time T2 is elapsed(operation S10).

At this time, when the DPDU is not received any more within the set timeT2 or when the DPDU in which the DC-ID is less than the DC-ID value ofthe device and in which the D-ID is the same as the D-ID of the deviceis not received, the device has the highest capability in the domain.Accordingly, the device is selected as the reference point controllerwhich is a representative in a domain (operation S11). The deviceselected as the reference point controller reports to the domain managerthat the device is selected as the reference point controller. Thedevice is registered as the reference point controller. Here, theregistration procedure will be described with reference to FIG. 13.

Software which can perform a function of the reference point controllermay be installed in the device that is selected as the reference pointcontroller. The software is previously installed in the device in adisabled status. When the device is selected as the reference pointcontroller, the software is enabled and established according to acommand of the domain manager. Alternatively, the domain manager oranother device may upload the software which can perform the function ofthe reference point controller to the selected device. It is assumedthat the domain devices which join in the procedure of selecting thereference point controller satisfy basic conditions for performing thefunction of the reference point controller. At this time, the basicconditions may represent that the disabled software is included or thathardware of software specifications in which a function of the referencepoint controller can be performed are satisfied.

As described above, according to Example 1-1 related to the selection ofthe reference point controller, the device with the highest capabilitycan be selected as the reference point controller by exchanging DPDUdata packets among devices. The aforementioned description is anexample. The setting of the capability through the DC-ID, the comparisonof the capability, and the like may be changed without departing fromthe spirit and scope of the present invention.

EXAMPLE 1-2

Hereinafter, Example 1-2 that is another example of a method ofselecting a reference point controller will be described.

In the method of selecting a reference point controller of Example 1-2,the devices (for example, client devices), which desire to be registeredwith the domain, report the device information of the devices to thedomain manager, and the domain manager selects the reference pointcontroller based on the reported device information. At this time, thedevice information may include information on the domain, which thedevice subscribes to, information on the capability of the device,identification information of the device, and the like. For example, thedevice information may be a DPDU.

FIG. 8 is a flowchart illustrating a method of selecting a referencepoint controller according to Example 1-2.

Referring to FIG. 8, when the procedure starts, the devices to subscribea domain set DC-ID values X, D-ID values Y, and DE-ID values Z topredetermined values (operation S20). At this time, the DC-ID set valuesare allocated according to a pre-determined standard or generated by thecorresponding devices.

For example, when the standard of the DC-ID values is specifications ofa central processing unit (CPU) embedded in the device, the DC-ID valueof each device is allocated by the administrator. Alternatively, theDC-ID value of each device is set as the generated capability value. Forexample, the DC-ID value of the device A is 4, the DC-ID value of thedevice B is 2, the DC-ID value of the device C is 3, and the DC-ID valueof the device D is 8.

At this time, as the specifications of the CPU is high, the DC-ID valueis assumed to be small. Specifically, as the DC-ID value becomes small,the device has a high capability. However, the present invention is notlimited thereto. Alternatively, it may be assumed that the DC-ID valueis set to be small as the battery capacity is small. In addition,according to execution environments, information on other hardwareexcept the CPU, energy information, and the like can be applied to thecapability of the device in various types.

The D-ID is set as a unique number or information data for displaying adomain which a device subscribes to. In addition, the DE-ID value ofeach device is initialized as codes for distinguishing the devices fromone another. The D-ID value and the DE-ID value may be allocated by theadministrator or generated by the corresponding device.

As described above, when setting of the DC-ID and the D-ID is completedfor each device, the device transmits the DPDU including the setinformation to the domain manager (operation S21). The DPDU may betransmitted within a predetermined time. The domain manager maintains astandby state during the predetermined time. When the predetermined timeis elapsed, the domain manager does not receive the DPDU any more.

The domain manager compares the DC-ID values included in the domainheader of the DPDU received from the devices with one another (operationS22) and extracts the device having the smallest DC-ID value, that is,the device having the highest capability (operation S23). When thedevice having the highest capability is extracted, the domain managerchecks the D-ID of the device (operation S24) and checks whether theD-ID is the same as an ID of the domain to be newly formed. When theD-ID is the same as the ID of the domain to be newly formed, the deviceis selected as the reference point controller (operation S25). Asdescribed in Example 1-1, the function of the reference point controllermay be installed in the device selected as the reference pointcontroller.

As the D-ID check result, when the D-ID of the device is not the ID ofthe domain to be newly formed, DC-ID values of the devices except thecorresponding device are compared with one another, and the devicehaving the highest capability is searched for. The device having thehighest capability can be selected as the reference point controller.

On the other hand, in the aforementioned Example 1-2, the referencepoint controller is selected based on the capability of each device.Alternatively, the reference point controller may be selected based on adegree of matching with the reference information, setting of a user,and the like, in addition to the capability.

For example, when the devices, which desire to be registered with thedomain, transmits the device information including information onhardware specifications of the devices to the domain manager, the domainmanager may select the most suitable devices by comparing thetransmitted device information with the predetermined specificationinformation. In addition, the domain manager may select a device matchedwith the device information, which is previously determined by the useramong the device information transmitted from each device, as thereference point controller.

EXAMPLE 1-3

In a method of selecting a reference point controller according toExample 1-3, the reference point controller is selected based on settinginformation that is previously set by an administrator or user or isarbitrarily set. For example, when the administrator or user inputs thesetting information into the domain manager, the domain manager canselect the reference point controller based on the setting information.Alternatively, the administrator or user may directly select the deviceto be used as the reference point controller by the user and establishthe reference point controller. Accordingly, in Example 1-3, the devicedesired by the administrator or user is selected, or any device isselected as the reference point controller.

The method of selecting the reference point controller, which is todetermine a range of the local area, when the domain is initiallyconstructed, has been described through Examples 1-1 to 1-3. When thereference point controller is selected, the range of the local area inwhich the client subscribes to the domain in the local status can bedetermined by the reference point controller.

On the other hand, the domain manager or license manager may exist atany location in the local area or external network area. When the domainmanager or license manager exists in the external network, a securedcommunication means reliably interacting with the domain has to besupported.

On the contrary, since the reference point controller is an entity whichdetermines the range and environments of the local area in the localarea, the reference point controller has to exist in the local area,unlike the domain manager or license manager. At this time, thereference point controller periodically and continuously communicatesinformation signals with the domain manager so as to verify that thereference point controller normally operates.

When the domain manager does not receive any information signal from thereference point controller for a predetermined time, this representsthat the reference point controller does not normally operate.Specifically, the reference point controller is out of order.Alternatively, the reference point controller becomes out of order sincethe reference point controller enters an external non-communicationarea.

In this case, the client devices in the local area, which subscribe tothe domain, may not normally use contents. Practically, since thereference point controller may be installed in a mobile phone, apersonal digital assistant (PDA), and the like, the reference pointcontroller may enter the external non-communication area. In this case,the reference point controller may malfunction.

Accordingly, in the present invention, a method of preparing against themalfunction of the reference point controller is disclosed. At first, aconcept of a reference point controller candidate is introduced. Thereference point controller candidate indicates a device which replacesthe reference point controller, when the reference point controllermalfunctions. The reference point controller candidate may be selected,when the domain is initially constructed or selected according to thedomain manager, after the domain is constructed.

—Selection and Operation of a Reference Point Controller Candidate—

There are four methods of selecting a reference point controllercandidate.

There is a first method in which the devices except the currentreference point controller among the devices in the domain communicatedevice information with one another. The device information is comparedwith one another based on a pre-determined algorithm, for example, thealgorithm described in Example 1-1, and the reference point controllercandidate is selected. For example, the capabilities are communicatedamong the devices. The device having the highest capability is selectedas the reference point controller candidate. The selected referencepoint controller candidate reports to the domain manager that the deviceis selected as the reference point controller candidate.

There is a second method in which the devices in the domain provide thedevice information on the devices (for example, the DPDU including thecapabilities) to the domain manager, and the domain manager selects thereference point controller candidate based on the device information,similar to the selection of the reference point controller according toaforementioned Example 1-2.

There is a third method in which the devices in the domain provides thedevice information of the devices to the reference point controller, andthe reference point controller selects the reference point controllercandidate based on the device information. In this case, when thereference point controller is selected, the reference point controllerhas to report information on the selected reference point controllercandidate to the domain manager.

There is a fourth method in which the reference point controllercandidate is selected based on the predetermined information. At thistime, the predetermined information may be set by the administrator oruser. Alternatively, the predetermined information may includearbitrarily set information.

Hereinafter, the aforementioned four methods will be described indetail. For convenience of understanding, the aforementioned firstmethod of selecting a reference point controller candidate is referredto as Example 2-1. The second method of selecting a reference pointcontroller candidate is referred to as Example 2-2. The third method ofselecting a reference point controller candidate is referred to asExample 2-3. The fourth method of selecting a reference point controllercandidate is referred to as Example 2-4.

EXAMPLE 2-1

FIG. 9 is a flowchart illustrating a procedure of selecting a referencepoint controller candidate according to Example 2-1. FIG. 9 illustratesa procedure of automatically selecting a reference point controller byusing a capability of a device.

The procedure of selecting the reference point controller candidateaccording to Example 2-1 may start, after the procedure of selecting thereference point controller is completed, when the domain is constructed.Alternatively, the procedure of selecting the reference point controllercandidate according to Example 2-1 may start according to a startcommand of an entity such as the domain manager at any time after thedomain is constructed.

As shown in FIG. 9, when the procedure starts, the devices except thereference point controller among the devices in the domain set thedevice information (operation S30).

The device information may include information on the capability,information on the domain, identification information of the device, andthe like. Here, the information on the capability may includeinformation on the energy residual amount of the device, a hardwarespecification, a network connection speed, mobility to outside,stability of a system, and the like. In addition, the information on thecapability may be a number like the DC-ID value. Alternatively, theinformation on the capability may be various types of information.

When setting of the device information (capability information, domaininformation, device identification information) for each device iscompleted, the device makes the set information into normalized packets,for example the device inserts the set information into the DPDU andsequentially broadcasts or multicasts the DPDU to another device(operation S31).

Then, each device receives the normalized packet transmitted fromanother device (operation S32), compares the capability informationincluded the received packet with the capability of the device(operation S33), and enables one device (the device that transmits thepacket or device that receives the packet) to fail in the selection(operation S34).

For example, the device, which receives the packet, compares thecapability information of the received packet with the capabilityinformation of the device. When the capability information of thereceived packet is greater than the capability of the device, the devicestops broadcasting the DPDU. That is, the device that receives thepacket fails in the selection of the reference point controllercandidate. At this time, a procedure of checking whether the device thattransmits the packet is in the same domain as the device that receivesthe packet from the information on the received packet may be alsoperformed. On the other hand, when the capability information of thereceived packet is less than the capability of the device that receivesthe packet, the packet is destroyed. That is, the device that transmitsthe packet fails in the selection of the reference point controllercandidate.

Finally, only a device having the highest capability remains through theaforementioned procedure (operation S35). Then, the survived device isselected as the reference point controller candidate (operation S36).The selected device reports to the domain manager that the device isselected as the reference point controller candidate.

The domain manager manages the information on the selected referencepoint controller candidate. When an error occurs in the reference pointcontroller, the reference point controller candidate can be used as anew reference point controller.

On the other hand, a plurality of reference point controller candidatesmay be registered with the domain manager, in priority order.Specifically, a procedure of selecting a first reference pointcontroller candidate is performed, and the first reference pointcontroller candidate is registered. A procedure of selecting a secondreference point controller candidate is performed, and the secondreference point controller candidate is registered. The aforementionedprocedures are repeatedly performed, and desired number of referencepoint controller candidates can be registered.

When the plurality of reference point controller candidates areregistered, the reference point controller can be replaced in thepriority order. At this time, the registered plurality of referencepoint controller candidates have to periodically verify that thereference point controller candidates normally operate. A procedure ofverification will be described in detail later.

EXAMPLE 2-2

In a method of selecting a reference point controller candidateaccording to Example 2-2, the devices in the domain reports the deviceinformation of the devices to the domain manager, and the domain managerselects the reference point controller candidate based on the reporteddevice information.

The method is similar to the concept of selection of the reference pointcontroller according to Example 1-2. In Example 1-2, the devices tosubscribe to the domain reports the device information of the devices tothe domain manager, and the domain manager selects the most suitabledevice based on the reported device information and registers theselected device as the reference point controller.

In Example 2-2, the devices in the domain except the reference pointcontroller provides device information of the devices to the domainmanager, and the domain manager selects the most suitable device basedon the reported device information and registers the selected device asthe reference point controller candidate.

At this time, the device information may include the capabilityinformation which represents the capability of the device according to apredetermined standard. The domain manager can register the devices byassigning priorities to the devices based on the capability informationprovided by the devices in the descending order of the capabilities.

For example, the domain manager can select and register a plurality ofreference point controller candidates in the order of the firstreference point controller candidate which can firstly replace thereference point controller, the second reference point controllercandidate, and the third reference point controller candidates,according to the capability information of each device. When theplurality of reference point controller candidates are registered, thereference point controller candidates replace the reference pointcontroller in the allocated priority order.

On the other hand, the procedure of selecting the reference pointcontroller candidate may be performed after the reference pointcontroller is selected. The reference point controller candidates may beselected, when the procedure of selecting the reference point controllerdisclosed in Example 1-2 is performed, according to executionenvironments. That is, the first reference point controller candidate,the second reference point controller candidate, and the like areselected, when the reference point controller is selected. For example,the devices to subscribe to the domain, when the domain is constructed,reports the information on the capability to the domain manager, and thedomain manager can select the reference point controller, the firstreference point controller candidate, the second reference pointcontroller candidate, and the like, based on the reported capability.

EXAMPLE 2-3

In a method of selecting the reference point controller candidateaccording to Example 2-3, the devices in the domain reports the deviceinformation of the devices to the domain manager, and the referencepoint controller selects the reference point controller candidates basedon the reported device information.

The method of selecting the reference point controller candidateaccording to Example 2-3 is substantially the same as the method ofselecting reference point controller candidates according to Example 2-2except that the reference point controller selects the reference pointcontroller candidates.

The device information reported to the reference point controller mayinclude the capability information which represents the capability ofthe device. The reference point controller can register the devices byassigning priorities to the devices based on the capability informationreported by the devices in the descending order of the capabilities. Forexample, the reference point controller can select and register aplurality of reference point controller candidates in the order of thefirst reference point controller candidate which can firstly replace thereference point controller, the second reference point controllercandidate, and the third reference point controller candidate, accordingto the capability information of each device. When the plurality ofreference point controller candidates are registered, the referencepoint controller candidates can replace the reference point controllerin the priority order.

On the other hand, when the reference point controller is selected, thereference point controller registers the selected reference pointcontroller candidate to the domain manager. In addition, even when theplurality of reference point controllers are selected in the priorityorder, the reference point controller reports the selection history tothe domain manager. Accordingly, event when the reference pointcontroller is out of order or enters a non-communication area for a longtime, the reference point controller candidate replaces the referencepoint controller. Thus, the service is normally provided.

EXAMPLE 2-4

In a method of selecting the reference point controller according toExample 2-4, the reference point controller candidate is selected basedon setting information that is previously set by the administrator oruser or is arbitrarily set. For example, when the administrator or userinputs the setting information into the domain manager or referencepoint controller, the domain manager or reference point controller canselect the reference point controller based on the setting information.

The setting information may include the information on the plurality ofreference point controller candidates to which the priorities areassigned. Specifically, the domain manager or reference point controllercan select the plurality of reference point controller candidates in thepriority order included in the setting information. For example, adevice A is selected and registered as a first reference pointcontroller candidate, and a device B is selected and registered as asecond reference point controller candidate. Then, when an error occursin the reference point controller, the first reference point controllercandidate can replace the reference point controller. When an erroroccurs in the first reference point controller candidate, the secondreference point controller candidate can replace the first referencepoint controller candidate.

In a case where the domain manager selects the reference pointcontroller candidates, when the domain is constructed, the domainmanager selects the reference point controller and designates thereference point controller candidates in the pre-determined priorityorder at the same time. Then, when the reference point controller is outof order, it is possible to flexibly and rapidly cope with the error. Onthe other hand, in a case where the reference point controller selectsthe reference point controller candidates, after the reference pointcontroller is selected, the reference point controller can designate thecandidates to replace the reference point controller based on thesetting information.

On the other hand, the administrator or user may directly select adevice to be used as a reference point controller candidate withoutusing the domain manager or reference point controller. In this case,the selected reference point controller candidate has to report to thedomain manager that the device is selected as the reference pointcontroller candidate.

The method of selecting the reference point controller candidates hasbeen described through Examples 2-1 to 2-4. In a case where thereference point controller is selected, even when an error occurs in thereference point controller, the reference point controller candidate canreplace the reference point controller. In addition, stability andflexibility of the service in the domain can be secured by setting theplurality of reference point controller candidates in the predeterminedpriority order.

The reference point controller candidates may have following functions.

1. A function of the reference point controller: for example,measurement of proximity to a predetermined device and issuing a domaincredential, and the like. The function of the reference point controllerhas been previously described.

2. A function of transmitting and receiving an information signal: thereference point controller candidate has to communicate the informationsignal for reporting that the reference point controller candidatenormally operates with the reference point controller and the likethrough a predetermined interface.

3. A function of setting non-receiving conditions: a function of settingconditions for distinguishing non-receiving of the information signal.For example, a time out, a count limit, a range limit, and the like maybe set.

4. A function of reporting to the domain manager: a function ofsupporting a data structure and an interface for communicating with thedomain manager.

5. A function of downloading: a function of supporting an interface fordownloading an entity (software) from the domain manager orpredetermined service terminal.

On the other hand, the reference point controller has to periodicallyverify that the reference point controller normally operates to thedomain manager or other devices. In addition, the reference pointcontroller candidates have to periodically verify that the referencepoint controller candidates normally operate to the domain manager orother devices. This is because the reference point controller candidatemay not replace the referent point controller, when an error occurs inthe reference point controller candidate.

FIG. 10 is a block diagram illustrating a reference point controller andconnections among reference point controller candidates for transmittingan information signal.

As shown in FIG. 10, designated routes a, b, and c for transmitting aninformation signal are formed between a reference point controller 70and reference point controller candidates 71 and 72 in the domain 6. Theroutes a, b, and c for transmitting an information signal representroutes for transmitting an information signal for verifying whether adevice normally operates.

For example, in the routes a, b, and c for transmitting an informationsignal, the reference point controller 70 transmits an informationsignal to a first reference point controller 71, and the reference pointcontroller candidate 71 transmits an information signal to a secondreference point controller 72. In addition, the second reference pointcontroller candidate 72 transmits an information signal to the referencepoint controller 70. At this time, the first reference point controllercandidate 71 denotes a primary reference point controller candidate, andthe second reference point controller candidate 72 denotes a secondaryreference point controller candidate.

A safe communication means or channel has to be provided in the routesa, b, and c for transmitting an information signal. In order to form thesafe communication means or channel, various encryption methods may beused. For example, a public key method, a method of previously sharing akey, a method in which the domain manager provides information on a keyto the devices, and the like may be used. Alternatively, a contenttransmission controller can provide information on a key, when secureauthenticated channels among a content exporter, a content transformer,and a content importer are generated.

A transmission signal is periodically transmitted through the routes a,b, and c for transmitting an information signal. The transmission signalserves to verify that the reference point controller or reference pointcontroller candidate normally operates. The transmission signal mayinclude domain information, device identification information, systeminformation, time-out information, and the like.

Here, the time-out information relates to a time limit for determiningwhether the information signal is normally received.

For example, when the information signal is not received from thereference point controller 70 within the time limit, the first referencepoint controller candidate 71 determines that an error occurs in thefirst reference point controller 70. The first reference pointcontroller candidate 71 reports to a domain manager that an error occursin the reference point controller 70 and that the first reference pointcontroller candidate 71 replaces the reference point controller 70.Then, the first reference point controller candidate 71 performs thefunction of the reference point controller 70.

At this time, the first reference point controller candidate 71 canreceive information and tools needed for performing the function of thereference point controller from the domain manager 60 or anotherterminal. For example, the first reference point controller candidate 71may download and install software for performing the function of thereference point controller or may enable disabled software installedtherein.

For another example, when the reference point controller 70 does notreceive the information signal from the second reference pointcontroller candidate 72 within the time limit, the reference pointcontroller 70 determines that an error occurs in the second referencepoint controller candidate 72 and reports to the domain manager 60 thatan error occurs in the second reference point controller candidate 72.Then, a reference point controller candidate having a lower prioritythan the second reference point controller candidate, for example athird reference point controller candidate (not shown) can replace thesecond reference point controller candidate 72. The priorities may benewly reconstructed through the aforementioned procedures (Examples 2-1to 2-4) of selecting reference point controller candidates.

On the other hand, in the example shown in FIG. 10, it is determinedwhether an error occurs in the device through transmission of aninformation signal among the reference point controller 70, and thereference point controller candidates 71 and 72. The present inventionis not limited thereto. As shown in FIG. 11, the reference pointcontroller 70 and the reference point controller candidates 71 and 72may directly transmit an information signal to the domain manager 60through routes e, f, and c. For another example, the reference pointcontroller 70 may directly transmit an information signal to the domainmanager 60, and the reference point controller candidates 71 and 72 maytransmit an information signal to each other through a predeterminedroute. That is, the routes for transmitting an information signal may bevariously changed according to execution environments.

As described above, the reference point controller 70 and the referencepoint controller candidates 71 and 72 periodically verify that theynormally operate by using an information signal. The reference pointcontroller 70 is replaced, or the priorities of the reference pointcontroller candidates 71 and 72 may be reconstructed depending onwhether the information signal is received.

On the other hand, a range of the local area determined by a singlereference point controller is physically or logically limited due to apolitical reason, and the like. However, a user may desire to use acontent service in a more extended range than that of the currently setlocal area. Accordingly, there is required a method in which a servicearea can be extended while the limit of the range of the local area ismaintained.

In the present invention, there is introduced a concept of a referencepoint controller proxy. The reference point controller proxy representsa device which performs the function of the reference point controllerinstead of the reference point controller. The reference pointcontroller proxy is needed when the domain is extended or when thereference point controller temporarily moves outside.

—Selection and Operation of the Reference Point Controller Proxy—

FIG. 12 is a block diagram illustrating a concept of a reference pointcontroller proxy. FIG. 12 illustrates an example in which a domain A′ isadded to a domain A.

As shown in FIG. 12, a range and an environment of a local area in whicha device can subscribe to a domain 86 is determined by a reference pointcontroller 82. When a service area is extended or the reference pointcontroller 82 temporarily moves outside of the local area, an extendeddomain having the same authority as the domain A, for example, thedomain A′ 96 has to be generated.

The range and the environment of the local area in which a device cansubscribe to the domain A′ 96 can be determined by a reference pointcontroller proxy 92. The reference point controller proxy 92 performsthe function of the reference point controller in the domain A′ 96. Thatis, the reference point controller proxy 92 is a reference point in thedomain A′ 96. The user can receive a content service from the domain A′96 in addition to the domain A 86 through client devices 84 and 94.

The reference point controller proxy 92 is easily selected through theprocedures described in the aforementioned examples of selecting thereference point controller and the reference point controllercandidates. That is, methods of selecting the reference point controllerproxy 92 will be described in the following.

In a first method, the devices to subscribe to the domain A′ 96communicate device information with one another. The device informationis compared with one another according to a predetermined algorithm, forexample, the algorithm described in Example 1-1. The reference pointcontroller proxy 92 is selected based on the device information. Forexample, the capabilities are communicated among the devices. The devicehaving the highest capability is selected as the reference pointcontroller proxy 92. The selected reference point controller proxy 92reports to the domain manager 80 that the device is selected as thereference point controller proxy 92.

In a second method, similarly to the concept of selecting the referencepoint controller according to Example 1-2, the devices to subscribe tothe domain A provide the device information (for example, the DPDUincluding the capability information) of the devices to the domainmanager, and the domain manager 80 selects the reference pointcontroller proxy 92 based on the device information.

In a third method, the reference point controller proxy 92 is selectedbased on setting information that is previously set by administrator oruser or is arbitrarily set.

On the other hand, when the reference point controller proxy 92 isselected, a candidate for preparing against a case where an error occursin the reference point controller proxy 92 may be selected. That is, acandidate, which replaces the reference point controller proxy 92 whenan error occurs in the reference point controller proxy 92, is selected.The candidate of the reference point controller proxy can be easilyselected by using the aforementioned procedures of selecting thereference point controller candidates.

Methods of selecting the candidate of the reference point controllerproxy 92 will be described in the following.

In a first method, the devices to subscribe to the domain A′ 96communicate device information with one another. The device informationis compared with one another according to a predetermined algorithm, forexample, the algorithm described in Example 1-1. The reference pointcontroller proxy 92 and the candidate of the reference point controllerproxy 92 are selected based on the device information. For example, thecapabilities are communicated among the devices. The device having thehighest capability is selected as the reference point controller proxy92. Subsequently, the candidate of the reference point controller proxyis selected by communicating the capabilities among the devices exceptthe reference point controller proxy 92. There are priorities in thecandidates of the reference point controller proxy. In addition, theselected reference point controller proxy 92 and the selected candidateof the reference point controller proxy 92 have to report to the domainmanager 80 that the devices are selected as the reference pointcontroller proxy 92 and the candidate of the reference point controllerproxy 92.

In a second method, similarly to the concept of selecting the referencepoint controller according to Example 1-2, the devices to subscribe tothe domain A′ provide the device information (for example, the DPDUincluding the capability information) of the devices to the domainmanager, and the domain manager 80 selects the reference pointcontroller proxy 92 and the candidate of the reference point controllerproxy 92 based on the device information. At this time, there may bepriorities in the candidates of the reference point controller proxy 92.

In a third method, the reference point controller proxy 92 and thecandidates of the reference point controller proxy 92 are selectedaccording to the priorities. At this time, the predetermined informationmay be set by the administrator or user. Alternatively, thepredetermined information may include arbitrarily set information.

On the other hand, the reference point controller proxy 92 has to reportto the reference point controller 82 that the reference point controllerproxy 92 continuously and stably provides a service. The reference pointcontroller proxy 92 periodically communicates a predeterminedinformation signal with the reference point controller 82. When theinformation signal is not communicated within a predetermined period,the reference point controller proxy 92 is not in a normal status.Accordingly, the domain A′ 96 cannot be maintained.

The domain reference information may include domain referenceinformation, device identification information, time-out information,unique system information, and the like.

The information signal has to be transmitted through a wired or wirelesstransmission route in which a safe communication means or channel isprovided. In order to form the safe communication means or channel,various encryption methods may be used. For example, a public keymethod, a method of previously sharing a key, a method in which thedomain manager provides information on a key to the devices, and thelike may be used. In addition, the information signal may becontinuously communicated between the reference point controller and thedomain manager and between the reference point controller proxy and thedomain manger, in addition between the reference point controller andthe reference point controller proxy.

On the other hand, when the domain A′ 96 needs not to be maintained, thedomain A′ 96 has to be destroyed. In this case, the domain A′ 96 can bedestroyed by using the information signal. For example, the referencepoint controller 82 or domain manager 80 stops the information signal tobe transmitted to the reference point controller proxy 92 or transmits adestroy signal. Then, since the reference point controller proxy 92 doesnot normally operate, the reference point controller proxy 92 isdestroyed. Accordingly, the domain A′ is automatically destroyed.

—Registration of the Reference Point Controller—

Hereinafter, a procedure of registering a new reference point controllerwill be described. The procedure of registering the reference pointcontroller may be performed when the new domain is generated or when thereference point controller is replaced.

FIG. 13 is a flowchart illustrating a procedure of registering areference point controller.

Referring FIG. 13, the domain manager receives a request forauthenticating the reference point controller from a device to beregistered as the new reference point controller. At this time, thedevice to be registered as the new reference point controller may be oneof the device selected from the aforementioned procedure of selectingthe reference point controller, the reference point controller candidateto replace the existing reference point controller, and the referencepoint controller proxy.

When the domain manager receives the request for authenticating thereference point controller, the domain manager invalidates an existingreference point controller membership. At this time, the reference pointcontroller membership is generated by the domain manager when thereference point controller is registered. The reference point controllermembership may represent information for verifying that thecorresponding entity is the reference point controller.

The domain manager generates and stores a unique new reference pointcontroller membership, and transmits the generated reference pointcontroller membership to the device which requests the domain manager toprovide the new reference point controller membership. At this time, thedomain manager stores and manages the reference point controllermembership and the domain as a pair.

The device which receives the reference point controller membershipstores the reference point controller membership. The device isregistered as the reference point controller. The stored reference pointcontroller membership can be used as authentication element informationwhen the newly registered reference point controller provides varioustypes of information to the domain manager or requests the domainmanager to provide the various types of information or when the clientis authenticated. In addition, the reference point controller membershipis periodically stored while the reference point controller ismaintained.

—A Method of Authenticating a Client—

Hereinafter, the method of authenticating the client will be described.Returning to FIG. 5, when the client 3 subscribes to the domain 5, thedomain manager 22 generates a client membership that is unique withrespect to the client 3. The client membership given to the client 3 iscontinuously stored, while the client is being a member of the domain 5.When the client 3 secedes from the domain 5, the domain manager 22maintains the client membership of the client during a predeterminedperiod and removes the client membership. At this time, even when theclient 3 secedes from the domain 5, a content that is used before thetime out is continuously used during the predetermined period. Thepredetermined period can be selectively applied by a policy of aprovider.

The client has to verify that the client normally subscribes to thedomain 5 to a pre-determined entity, so that the client 3 whichsubscribes to the domain 5 uses a service. For this, the client 3requests the domain manager 22 to authenticate the client 3. When theclient 3 requests the domain manager 22 to authenticate the client 3,the client 3 has to submit a clear credential or automatic credential tothe domain manager 22.

The clear credential is encrypted information including the clientmembership given to the client 3 and the clear domain credential. Atthis time, the clear domain credential is generated by the domainmanager 22, when the domain 5 is generated. The domain manager 22applies the generated domain credential to various transactions formanaging the domain after the domain 5 is generated.

The automatic credential is encrypted information including a referencepoint controller membership and a client membership. The automaticcredential may represent the domain credential provided by the referencepoint controller 26. The reference point controller membership isgenerated by the domain manager 22, when the reference point controller26 is registered with the domain 5. The reference point controllermembership is continuously stored while the reference point controller26 is maintained. The automatic credential is information on whether theclient 3 normally exists in the local area, which is guaranteed by thereference point controller 26. Accordingly, the client 3 in the localstatus can use the automatic credential.

When the client 3 requests the domain manager 22 to authenticate theclient 3, the domain manager 22 determines whether the submittedcredential is valid. When it is determined that the client 3 dose notsubscribe to the domain 5, the domain manager 22 generates an error.Alternatively, when the client 3 normally subscribes to the domain 5,the domain manager 22 authenticates the client 3. The client 3 can use acontent within an authorized range.

The domain manager 22 recognizes that the client 3 is in the remotestatus or local status depending on whether the credential submitted bythe client 3 is the clear credential or automatic credential and managesthe client 3. As described above, the remote status may represent a casewhere the client 3 accesses the domain 5 in the network area outside ofthe local area. For example, the client 3 accesses the domain 5 throughthe Internet. On the other hand, the local status may represent a casewhere the client 3 exists in the local area. The reference pointcontroller 26 can check the client 3 in the local status by measuringthe number of hops. The client 3 may be registered with the domain 5 asa member through the predetermined procedure.

—Registration, Authentication, and Management of a Legacy Device—

The legacy device in addition to the client device can also access tothe domain. At this time, the legacy device may represent a device onwhich an entity that operates as a client in the domain is notcompletely mounted. Specifically, a device having only some functions ofthe client or a device in which the client is not included is referredto as the legacy device.

In order to allow the legacy device to be provided with a service in thedomain, the client part includes an adapter for allowing the legacydevice to access a system, that is, an interface entity. The interfaceentity has to provide various functions so that the legacy deviceperforms a function equivalent to the client device.

The aforementioned interface entity is referred to as a virtual client.The virtual client is an entity needed to link the legacy device withthe system. The virtual client allows the legacy device to be providedwith the service like the client device, in linkage with the legacydevice. Specifically, the domain manager considers the access of thevirtual client and the legacy device to the domain as the access of oneclient to the domain. One or more legacy devices may be connected to thevirtual client.

The virtual client or domain manager can manage unique information ofthe legacy device. In addition, the virtual client or domain manageralso manages information on a user who uses the legacy device.

FIG. 14 illustrates an example of a structure for managing uniqueinformation of a legacy device.

As shown in FIG. 14, when a legacy device 210 requests the virtualclient 220 to be accessed by the legacy device 210, unique informationon the legacy device DV-info is provided to the virtual client. At thistime, the unique information DV-info on the legacy device may representunique information such as a media access control address, a disk volumeID, and the like, which is unique for the legacy device 210.

The unique information DV-info on the legacy device may be transmittedto the virtual client 220 together with the request for an accessrequest message, when the legacy device 210 requests the virtual clientto be accessed. Alternatively, the virtual client 220 may extract theunique information DV-info on the legacy device from the legacy device210, when the legacy device 210 requests the virtual client 220 to beaccessed.

The virtual client 220 can store and manage the unique informationDV-info on the legacy device provided by the legacy device 210. At thistime, as shown in FIG. 14, the unique information DV-info on the legacydevice can be stored and managed in a form of an information table 222in correspondence with a device identifier LD-info. Here, the deviceidentifier LD-info is globally unique identification information foridentifying the legacy device 210. The device identifier LD-info may beassigned by the domain manager 240.

The domain manager 240 stores and manages the device identifier LD-infoand the unique information DV-info on the legacy device corresponding tothe device identifier LD-info for each domain. For example, as shown inFIG. 14, the domain manager 240 can store and manage the domainidentifier D-ID, the device identifier LD-info, and the uniqueinformation DV-info on the legacy device corresponding to the domainidentifier D-ID and the device identifier LD-info in a form of aninformation table 242. At this time, the domain identifier D-ID isinformation for identifying the domain accessed by the legacy device210. The domain identifier D-ID may also be information for identifyingthe domain 200 in which the virtual client 220 is included.

When the domain manager 240 manages the device identifier LD-info andthe unique information DV-info on the legacy device corresponding to thedevice identifier LD-info, the domain manager 240 can prevent the legacydevice 210 from doubly requesting another domain to authenticate thelegacy device 210. This will become apparent through a method ofauthenticating the legacy device to be described in the following.

FIG. 15 is a flowchart illustrating a procedure of authenticating alegacy device.

Referring to FIGS. 14 and 15, when a predetermined legacy device 210requests the virtual client 220 to be accessed (operation S41), thevirtual client 220 receives the unique information DV-info on the legacydevice from the legacy device 210 (operation S42). Subsequently, thevirtual client 220 searches the information table 222 stored therein(operation S43) and determines whether there is unique information onthe legacy device that is the same as the unique information DV-info onthe legacy device which requests the virtual client 220 to be accessed(operation S44). That is, it is determined whether the legacy device 210is previously registered.

At this time, when there is the same unique information on the legacydevice as the unique information DV-info on the legacy device whichrequests the virtual client 220 to be accessed, since the legacy device210 is already registered with the virtual client 220, the virtualclient requests the domain manager 240 to authenticate the deviceidentifier LD-info (operation S46). When the domain manager 240 isrequested to authenticate the device identifier LD-info, the deviceidentifier LD-info and the unique information DV-info on the legacydevice may be provided to the domain manager 240.

On the other hand, when it is determined that there does not exist thesame unique information on the legacy device as the unique informationDV-info on the legacy device which requests the virtual client 220 to beaccessed, the virtual client 220 receives a new device identifierLD-info from the domain manager 240 and stores the new device identifierLD-info in the information table 222 (operation S45). Accordingly, theunique information DV-info on the legacy device and the newly allocateddevice identifier LD-info are equivalently stored in the informationtable 222. That is, the legacy device 210 is registered as a new device.

In order to register the legacy device, the virtual client 220 or domainmanager 240 examines the unique information on the legacy device 210 andexamines whether the legacy device 210 is a device which can beregistered. At this time, the device which can be registered mayrepresent a device which is politically and technically allowed device.For example, a service provider, another authority, the domain manger,and the like manage a list of types of the legacy device which canaccess the domain. When a new legacy device is registered, the virtualclient or domain manager examines the list of types of the legacy deviceand allocates device identifiers only to allowed devices. This will bedescribed in detail with reference to FIG. 17.

When the device identifier LD-info is stored, the virtual client 220requests the domain manager 240 to authenticate the device identifierLD-info (operation S46).

Next, the domain manager 240 authenticates the device identifier LD-infoin consideration of the unique information DV-info on the legacy devicecorresponding to the device identifier LD-info in response to therequest for authentication. Specifically, the domain manager 240searches the information table that is managed by the domain manager 240(operation S47) and determines whether the legacy device 210 accessesanother domain (operation S48). For example, the domain manager 240determines whether unique information on a legacy device that is thesame as the unique information on the legacy device is currentlyauthenticated.

When it is determined that the legacy device 210 does not access anotherdomain, it is reported to the virtual client 220 that the deviceidentifier LD-info is allowed to access the domain (operation S50). Thatis, the legacy device 210 is allowed to access the domain. Accordingly,the legacy device 210 can access the domain 200 and use a content.

On the other hand, when it is determined that the legacy device 210accesses another domain, it is determined that the legacy device intendsto doubly access domains. The determination result is reported to thevirtual client 220 (operation S49). That is, the legacy device 210 isnot allowed to access the domain. Accordingly, the legacy device 210cannot access the domain 200.

As described above, the virtual client 220 and the domain manager 240store and manage the unique information on the legacy device 210. Forexample, the virtual client 220 and the domain manager 240 store andmanage a device certificate of the legacy device.

Thus, the legacy device 210 may be prevented from doubly accessing thedomain 200. Accordingly, the legacy device 210 can be prevented fromillegally sharing a content.

On the other hand, the virtual client and the domain manager may manageinformation on a user who uses the legacy device in addition to theunique information on the legacy device. In this case, the number oflegacy device which can be used by the user may be limited.

FIG. 16 illustrates an example of a structure of a DRM interoperablesystem for managing information on a user who uses a legacy device.

As shown in FIG. 16, when the legacy device 251 accesses the virtualclient 260 so as to request the domain to authenticate the legacy device251, the unique information DV-info on the legacy device and userinformation U-info of the legacy device 251 are provided to the virtualclient 260. At this time, the user information U-info of the legacydevice 251 may represent unique information for identifying the user whouses the legacy device 251 such as subscriber identification moduleinformation, user certificate information, or information which isclearly input by the user, for example, ID, password, and the like. Thismay correspond to system logon information of the user. As describedabove, the unique information DV-info on the legacy device may representunique information such as a media access control address, a disk volumeID, and the like, which is unique for the legacy device 210. That is,the unique information on the legacy device indicates informationincluding physical information or logical information.

The user information U-info and the unique information DV-info on thelegacy device may be transmitted to the virtual client 260 together withan access request message, when the legacy device 251 requests thevirtual client 260 to be accessed. Alternatively, the virtual client 260may extract the user information U-info and the unique informationDV-info on the legacy device from the legacy device 251, when the legacydevice 251 requests the virtual client 260 to be accessed.

The virtual client 260 stores and manages the unique information DV-infoon the legacy device and the user information U-info. At this time, asshown in FIG. 16, the unique information DV-info on the legacy deviceand the user information U-info can be stored and managed in a form ofan information table 262 in correspondence with a device identifierLD-info provided by the domain manager 270.

The domain manager 270 stores and manages the device identifier LD-info,the unique information on the legacy device DV-info, and userinformation for each domain. Specifically, as shown in FIG. 16, thedomain manager 270 can store and manage the domain identifier D-ID, thedevice identifier LD-info, the unique information DV-info on the legacydevice, and the user information U-info in a form of an informationtable 272.

When the request for authenticating a predetermined legacy device 251 istransmitted from the virtual client 260, the domain manager 270 canapply the user information U-info of the legacy device 251 to anauthentication for permitting an access by searching the informationtable 272 of the domain manger 270 for the user information U-info ofthe legacy device 251. In addition, the management of the legacy device251 by the domain manager 260 can be applied to a general client device.

For example, the number of the legacy devices 251 is extracted bysearching the information table 272 for the user information U-info. Thenumber of the legacy devices 251 is compared with a predetermined numberlimit. When the number of the legacy devices 251 is less than thepredetermined number limit, an authentication is performed. When thenumber of the legacy devices 251 is equal to or greater than thepredetermined time limit, the authentication is not allowed.Accordingly, the total number of the legacy devices of the user can belimited. At this time, the number limit will depend on a policy of aservice provider or costs paid by the user.

As described above, when the legacy device 251 is authenticated, aprocedure of determining whether the domain is doubly accessed bysearching for the unique information DV-info on the legacy device can bealso performed. That is, in the authentication procedure, it is checkedwhether the domain is doubly accessed, and the allowed number limit forthe user is considered by using the unique information on the legacydevice and the user information U-info. On the other hand, it may beperiodically checked whether the domain is doubly accessed, and thenumber of the legacy devices for each user may be periodically limitedaccording to a predetermined period.

FIG. 17 is a flowchart illustrating a procedure of registering a legacydevice to a domain.

Referring to FIG. 17, when a new legacy device requests the virtualclient to be accessed so as to subscribe to the domain (operation S51),the unique information on the legacy device is provided to the virtualclient. Then, the virtual client recognizes that the virtual client is anew legacy device through the unique information on the legacy deviceand searches the list of the legacy devices which can be registered(operation S52). The list of the legacy devices which can be registeredincludes objects of devices which can be politically and technicallyprovided with a service. The list may be previously stored by thevirtual client. Alternatively, the list can be provided by the domainmanager, a server of the service provider, or another system.

The virtual client searches the list based on the unique information onthe legacy device and determines whether the legacy device can beregistered (operation S53). For example, it is determined whether theunique information on the legacy device exists in the list. At thistime, when the unique information on the legacy device exists in thelist, the virtual client requests the domain manager to register thelegacy device. Then, the domain manager generates a unique deviceidentifier and transmits the unique device identifier to the virtualclient (operation S54). Alternatively, when the unique information onthe legacy device does not exists in the list, the virtual client doesnot allow the registration of the legacy device and reports informationon whether the legacy device can be registered to the legacy device(operation S55).

Up to now, referring to FIGS. 5 to 17, operations which can be performedby the authentication and management part, for example, the function ofthe client part, the procedure of selecting the reference pointcontroller, the procedure of selecting the candidates of the referencepoint controller, the procedure of replacing the reference pointcontroller by using the reference point controller candidate when anerror occurs in the reference point controller, the procedure ofextending the domain through the reference point controller proxy, theprocedure of selecting and using the candidate of the reference pointcontroller proxy, the procedure of registering the reference pointcontroller, the procedure of authenticating the client, the procedure ofregistering, authenticating, and managing the legacy device, and thelike are described.

3. Functions and Operations of the Processing Control Part and theContent Processing Part

When a domain is constructed by the authentication and management part,the authenticated client or legacy device (connected to the virtualclient) in the domain can use a DRM interoperable service. At this time,the legacy device and the virtual client connected thereto can beconsidered as one client. Accordingly, the following client may includea client constructed by connecting the legacy device to the virtualclient in addition to the client defined in the description of FIG. 2.

The authenticated client can request a predetermined destination deviceto transmit one or more contents. At this time, the destination deviceindicates a device or system in which the client desires to transmit apredetermined content, for example, another client device, apredetermined web server, or a system.

The request for transmission of the content may be received by theprocessing control part. The processing control part controls thecontent processing part so as to transmit the content in response to therequest for transmission of the content. The content processing parttransmits one or more contents requested to be transmitted to thedestination device under a control of the processing control part.

Hereinafter, the procedure of transmitting a content by the processingcontrol part and the content processing part will be described indetail. In the following description, four methods will be exemplifiedin relation to the transmission of a content in the DRM interoperablesystem. For convenience of understanding, a first method is referred toas Example 3-1. A second method is referred to as Example 3-2. A thirdmethod is referred to as Example 3-3. A fourth method is referred to asExample 3-4.

EXAMPLE 3-1

FIG. 18 is a block diagram illustrating structures of a processingcontrol part and a content processing part. FIG. 18 illustrates entitiesrelated to the procedure of transmitting a content.

As shown in FIG. 18, the processing control part 40 includes the contentprocessing controller 41 and a license processing controller 42. Here,since the license processing controller 42 does not relate to thetransmission of a content, the detailed description will be describedlater.

The content processing controller 41 serves to request the contentprocessing part 50 to transmit the content according to the request fortransmitting the content from the client and control the procedure oftransmitting the content. The content processing controller 41 may existat any location in the local area or network area. Preferably, thecontent processing controller 41 may included in a predetermined devicethat subscribes to the domain in the local area.

The content processing part 50 includes a plurality of content handlers.A content handler may indicate an entity which performs a functionrelated to the transmission and processing of a content. The contenthandler includes a content exporter 52, a content transformer 51, and acontent importer 53.

The content exporter 52 performs the function of transmitting thecontent to the content transformer 51 or content importer 53 in aneutral content form by exporting the content, which is requested to betransmitted by the content processing controller 41. At this time, theneutral content may indicate a clean content which is not encrypted byusing a predetermined DRM. In addition, the content requested by thecontent processing controller 41 may be a content encrypted by using apredetermined DRM. The content exporter 52 decrypts the requestedcontent, transforms the decrypted content into the neutral content, andtransmits the transformed content. Alternatively, the content exporter52 may receive a previously decrypted neutral content and transmit thereceived content.

The content transformer 51 serves to receive the neutral contenttransmitted from the content exporter 52, transform the neutral contentinto a content with a required format, and transmit the content with therequired format to the content importer 53. At this time, the requiredformat indicates a format required by a destination device DV2. Thecontent transformer 51 participates in the transmission, only whenformat trans-formation of the neutral content is needed.

The content importer 53 serves to receive the neutral contenttransmitted from the content transformer 51 or content importer 52. Inaddition, the content importer 53 may provide the received neutralcontent to the destination device DV2. Alternatively, the contentimporter 53 may encrypt the received neutral content into a content witha format suitable to the DRM applied to the destination device DV2 andprovide the encrypted content to the destination device DV2. At thistime, in the former case, the destination device DV2 encrypts theneutral content transmitted from the content importer 53 into thecontent with the format suitable to the DRM applied to the destinationdevice DV2 and uses the content. In the latter case, since the contentthat is encrypted by the content importer 53 is transmitted, thedestination device DV2 can use the transmitted content as it is.

FIGS. 19 and 20 show examples for illustrating locations of a contentprocessing controller 41 and content handlers.

As shown in FIGS. 19 and 20, the content controller 41 and the contenthandlers, that is, the content exporter 52, the content transformer 51,and the content importer 53 are located at various locations accordingto execution environments.

First, referring to FIG. 12, the content exporter 52 may be included ina request device DV1. The content importer 53 may be included in thedestination device DV2. In addition, the content processing controller41 or content transformer 51 may be included in other devices separatelyfrom the request device DV1 and the destination device DV2.

Here, the request device DV1 and the destination device DV2 need to bedefined.

The request device DV1 indicates a client device which requests acontent to be transmitted. A request client RC1 may be included in therequest device DV1. In addition, a predetermined DRM may be installed inthe request device DV1. That is, the request device DV1 can use acontent to which the predetermined DRM is applied.

As described above, the destination device DV2 indicates a client deviceor pre-determined system to which the content requested by the requestclient RC1 is transmitted. A destination client RC2 may be included inthe destination device DV2. In addition, a destination DRM may beinstalled in the destination device DV2. That is, the destination deviceDV2 can use a content to which the destination DRM is applied.

Referring to FIG. 20, the content processing controller 41 and thecontent exporter 52 are included in the request device DV1, and thecontent importer 53 is included in the destination device DV2. Inaddition, the content transformer 51 is separately included in anotherdevice.

As described above, the content processing controller 41, the contentexporter 52, the content transformer 51, and the content importer 53 maybe located at various locations. It may be advantageous for securityreasons that the content exporter 52 is included in the request deviceDV1, and the content importer 53 is included in the destination deviceDV2.

Accordingly, hereinafter the present invention will be described byemploying a structure shown in FIG. 19. However, the present inventionis not limited thereto. That is, the content processing controller 41and the content handlers may be included in the same device, accordingto execution environments. Selectively, some of the content processingcontroller 41 and the content handlers may be include in the samedevice, according to execution environments. Selectively, the contentprocessing controller 41 and the content handlers may be included inseparate devices, according to execution environments.

Hereinafter, the procedure of transmitting a content based on theaforementioned system will be described in detail.

FIG. 21 is a flowchart illustrating a procedure of transmitting acontent by using a content processing controller 41 and contenthandlers. FIG. 21 illustrates an example of a procedure of transmittingone or more contents included in the request device DV1 to thedestination device DV2 that is a destination.

As shown in FIG. 21, in order to transmit a content, the request clientRC1, the content processing controller 41, the plurality of contenthandlers, for example, the content exporter 52, the content transformer51, and the content importer 53 are required to interact with oneanother.

First, the request client RC1 transmits a content transmission requestmessage for requesting one or more contents to be transmitted to thecontent processing controller 41 (operation S60).

At this time, the content transmission request message includes atransmission session identifier, a content identifier, sourceinformation, destination information, and the like. In addition, DRMsystem information of the destination which receives the content may beincluded in the content transmission request message as an option.

The content identifier may indicate information for identifying thecontent requested to be transmitted. When there are a plurality ofcontents requested to be transmitted, a plurality of content identifiersfor identifying the contents may exist.

The transmission session identifier indicates an identifier for uniquelyidentifying a transmission session. The transmission session identifiermay be used to identify sessions when a predetermined operation isperformed, for example, when the content transmission is cancelled orwhen the content transmission status is updated.

The source information is used to determine from where the requestedcontent is transmitted. The source information may include an identifierfor identifying a source device or system such as the request deviceDV1, information on a format of a content file requested to betransmitted, and the like.

The destination information includes information for identifying thedestination device DV2 that is the destination to which the requestedcontent is transmitted. The destination information may include adestination identifier for identifying the destination, information on afile format required by the destination, and the like. The informationon the file format included in the destination information can bereferred, when the format of the file is transformed by the contenttransformer 51.

The content transmission controller 41 can use information included inthe content transmission message as in the following. At this time, thecontent transmission controller 41 may use the information received fromthe request client RC1 as it is. Alternatively, the content transmissioncontroller 41 may generate separate information corresponding to theinformation received form the request client RC1 and use the generatedinformation. For example, the content transmission controller 41 may usethe transmission session identifiers and a plurality of data identifiersreceived from the request client RC1 as they are. Alternatively, thecontent transmission controller 41 may use generate transmission sessionidentifiers and a plurality of data identifiers suitable for sessions.

When receiving the content transmission request message, the contentprocessing controller 41 gathers information on the content handlers,checks whether the content can be transmitted, and determines a contenthandler to transform a content, that is, a content handler to constructa content transformation chain (operations S61 to S63).

For example, the content processing controller 41 queries one or moreexporters 52, the content importer 53, and the content transformer 51about the capability and receives a response from the correspondingentity. Accordingly, the capabilities of the sources, midway anddestination devices, systems, and DRMs can be recognized.

When information is gathered, the content processing controller 41determines whether the requested content is to be transmitted based onthe gathered information.

That is, it is checked whether the content handlers normallytransmission the requested content. Here, the format of the requestedcontent, the policy of the system, and secure authenticated channelalgorithm information which can be executed among entities may beconsidered. For example, when the content transformer 51 cannot supporttransformation of a content into a content with a required format basedon the gathered capability of the content transformer 51, it isimpossible to transmit the content. When the content transformer 51 cansupport the transformation of the content into the content with therequired format, it is possible to transmit the content. The contentprocessing controller 41 determines whether the content is transmittedby considering the aforementioned factors.

When it is determined that the content is transmitted, the contentprocessing controller 41 determines the content handlers, for example,the content exporter 52, the content transformer 51, and the contentimporter 53, which can effectively perform the transformation of therequested content, and controls the content handlers so that a contenttransformation chain including the determined content handlers isconstructed.

That is, the determined content handlers are controlled so as toconstruct the content transformation chain.

When determining the content handlers included in the contenttransformation chain, the content transmission controller may includethe content transformer 51 or may not include the content transformer51. When the format of the content requested to be transmitted isdifferent from that of a content required by the destination, the formatof the transmitted content has to be transformed. However, when theformat of the content requested to be transmitted is the same as that ofa content required by the destination, the format of the transmittedcontent needs not to be transformed.

Accordingly, when the format of the requested content is different fromthe format required by the destination, the content processingcontroller 41 allows the content transformer 51 to be included in thecontent transformation chain. When the format of the requested contentis the same as the format required by the destination, the contentprocessing controller 41 allows the content transformer 51 not to beincluded in the content transformation chain. Here, the formattransformation of the content may indicate codec transformation.

For example, when the requested content is compressed by MPEG-2compression, and when the format of the content available in thedestination is MPEG-4, the content with a MPEG-2 format is notavailable, and therefore, the MPEG-2 format has to be transformed intoMPEG-4 format by using the content transformer 51.

In Example 3-1, a case where the content needs to be transformed sincethe format of the requested content is different from the formatrequired by the destination will be described. In this case, the contenttransformation chain has to include the content transformer 51.

Subsequently, the content processing controller 41 sends a contentexport request, a content transformation request, and a content importrequest respectively to the content exporter 42, the content transformer51, and the content importer 53 (operations S67 to S69). Theaforementioned requests are performed by transmitting a control messagefor requesting the content handlers to perform the requested operationsto the content handlers.

The control message for requesting the content to be exported mayinclude a transmission session identifier, a content identifier,receiver information, and the like. The receiver information mayindicate information on a receiver to which the content exporter 52exports and transmits the content. In Example 3-1, a case where thecontent transformation chain includes the content transformer 51 isdescribed, and therefore, the receiver information may indicateidentification information of the content transformer 51. However, whenthe content transformation chain does not include the contenttransformer 51, the receiver information may indicate the identifierinformation of the content importer 53.

In addition, the control message for requesting the content to betransformed may include the transmission session identifier, the contentidentifier, transmitter information, the receiver information, formatinformation of the content to be transmitted, information on atransformed format, and the like. At this time, the transmitterinformation and the receiver information may indicate information foridentifying an entity which transmits the content and an entity whichreceives the content. That is, the transmitter information serves toidentify the content exporter 52 which is a transmitter, and thereceiver information serves to identify the content importer 53 which isa receiver.

The control message for requesting the content to be imported mayinclude the transmission session identifier, the content identifier, thetransmitter information, and the like. The transmitter information mayindicate information for identifying the transmitter which transmits thecontent. In Example 3-1, a case where the content transformer 51 existsis described, and therefore, the source information may indicate theidentification information of the content transformer 51. When thecontent transformer 51 is not included in the content transformationchain, the content exporter 52 becomes the transmitter. When the contentis requested to be received, information on the receiver which finallyreceives the content may include destination information and the DRMsystem information of the destination.

In addition, when the content is requested to be exported, transformed,and received, the content identifier included in the control message ismatched with the content identifier requested when the client requeststhe content to be transmitted. When there are a plurality of contentsrequested by the client to be transmitted, the identifier of therequested content when the content is requested to be transmitted is thesame as the content identifier included in the content export requestinformation, the content transformation request information, and thecontent import request information.

As described above, when the content exporter 52, the contenttransformer 51, and the content importer 53 respectively receive thecontent export request, the content transformation request, and thecontent import request from the content processing controller 41, secureauthenticated channels (SACs) are established between the contentexporter 52 and the content transformer 51 and between the contenttransformer 51 and the content importer 53 (operation S70). At thistime, a security technique such as a transport layer security, which isapplied to a transport layer of TCP/IP, can be applied to the SACs.

The content exporter 52 establishes a SAC with the content transformer51 so as to safely transmit the requested content to the contenttransformer 51 which is a receiver, in response to the content exportrequest. In addition, the content transformer 51 transforms the contenttransmitted from the content exporter 52 and establishes a SAC fortransmitting the transformed content to the content importer 53, inresponse to the content transformation request. On the other hand, thecontent importer 53 may establish a SAC for transmitting the contenttransmitted from the content transformer 51 to the destination deviceDV2, that is, an end-point of transmission of the content, in responseto content import request. This is more useful when the content importeris installed in a device different from the destination device.

Accordingly, the SAC which constitutes a path from the content exporter52 to the content importer 53 via the content transformer 51 isestablished. In addition, the SAC through which the content importer 53provides the content to the final end-point may be established from thecontent importer to the end-point. Each content handler can report tothe content processing controller 41 that the SACs are established(operations S71 to S73).

When the SACs are established, the content starts to be transmitted fromthe content exporter 52. At this time, pairs of content handlersconnected to each other (that is, the content exporter 52—the contenttransformer 51 and the content transformer 51—the content importer 53)support a multi-transmission protocol. The multi-transmission protocolserves to enable multi-contents to be transmitted in a single session.This may support a variable frame size. Accordingly, it is possible totransmit a plurality of contents through a single session.

FIG. 22 shows an example for illustrating a multi-transmission protocol.

As shown in FIG. 22, it is possible to transmit a plurality of contentsin a single session. A content index is inserted into each contentheader. The content index may be a value with predetermined bits (forexample, four bits) for identifying the content. The content index is afactor for distinguishing the contents transmitted through thecorresponding session from one another in linkage with the requestedcontents. In addition, a content separator for distinguishing thecontents from one another is inserted into the end of the content. Forexample, the content separator may be constructed with four bits of 0.

The content may be divided into a plurality of frames according to thelength of the content. A frame size with predetermined bits (forexample, four bits) is inserted into a frame header. A frame payload forcarrying data is located behind the location of the frame size. On theother hand, an end-of-transmission (EOT), which represents an end oftransmission, is inserted into the last part of the session. Forexample, the EOT may be four bits of 1.

A plurality of contents can be transmitted through a sessioncorresponding to the transmission session identifier provided by therequest client RC1, according to the support of the multi-transmissionprotocol. The aforementioned transmission is sequentially performed fromthe content exporter 52. The content exporter 52 sends the requestedcontents to the content transformer 51 through the SAC (operation S74).The content transformer 51 receives the contents and performs formattransformation into the format required by the destination (operationS75). After the format transformation is performed, the contenttransformer 51 transmits the transformed contents to the contentimporter 53 through the SAC (operation S76). Then, the content importer53 receives the contents and provides the received contents to thedestination device DV2.

The contents which are transmitted from the content exporter 52 to thecontent importer 53 via the content transformer 51 may be neutralcontents. A neutral content may indicate a clean content which is notencrypted by using a predetermined DRM. The content exporter 52 mayexport the requested contents, transform the exported contents into theneutral contents, and transmit the neutral contents. Alternatively, thecontent exporter 52 may export previously transformed neutral contentsand transmit the neutral contents. This procedure can be performed inconsideration of a policy or export procedure designated by the DRMapplied to the requested content.

In addition, the content importer 53 can transmit the received neutralcontents to the destination device in consideration of a policy orimport procedure designated by the DRM system applied to the destinationdevice. For example, the neutral contents may be encrypted suitably tothe destination DRM and provided to the destination device DV2.Alternatively, the received neutral contents may be provided to thedestination device DV2 without encryption.

On the other hand, the content exporter 52, the content transformer 51,and the content importer 53 can report the transmission status of thecontents to the content processing controller 41. For this, the contentprocessing controller 41 has to subscribe to a predetermined eventthrough which the transmission status of the content can be provided.The predetermined event is referred to as a content-transmission-statusproviding event.

The content processing controller 41 can request thecontent-transmission-status providing event to be subscribed to, beforerequesting the content to be exported (operations S64 to S66). Forexample, the content processing controller 41 can subscribe to thecorresponding events by requesting the content exporter 52, the contenttransformer 51, and the content importer 53 to subscribe to thecontent-transmission-status event.

When subscribing to the content-transmission-status event, the contentprocessing controller 41 can receive an event message including thecontent-transmission-status information in a push or pull manner. Atthis time, in the push manner, the content handler automatically pushesthe event message (including the content-transmission-statusinformation), whenever the content-transmission-status changes.Accordingly, the content processing controller 41 can automaticallyreceive the content-transmission-status. In the pull manner, the contentprocessing controller 41 obtains the content-transmission-statusinformation from the content handler at need.

When subscribing to the event, the content processing controller 41reports the content handlers whether the content-transmission-statusinformation is provided in the push or pull manner. In Example 3-1, anexample in which the content-transmission-status is provided to thecontent processing controller 41 in the push manner is described.

When subscribing to the content-transmission-status providing event, thecontent processing controller 41 can receive the event message includingthe content-transmission-status information from the content handlers.At this time, a transmission session identifier has to be included inthe event message. Here, a transmission session identifier is the sameas the transmission session identifier allocated when the content isrequested to be provided.

When the content starts to be transmitted, the content exporter 52 sendsan event message for representing that the content starts to betransmitted to the content processing controller 41. For example, anevent message including a “Started” element may be transmitted. Inaddition, an event message for representing that the content is beingprocessed may be periodically transmitted to the content processingcontroller 41 during the transmission of the content. For example, anevent message including a “ProgressDone” element may be transmitted.When the transmission of the content is completed, the content exporter52 transmits an event message for representing that the transmission ofthe content is completed to the content processing controller 41. Forexample, an event message including a “Completed” element may betransmitted. In addition, event messages are generated for eachprocedure based on the event information on all the procedures oftransforming and transmitting data including a content or license inaddition to start, processing, and end procedures, and transmitted.

When the content starts to be transmitted, the content transformer 51sends the event message for representing that the content starts to betransmitted to the content processing controller 41. For example, anevent message including a “Started” element may be transmitted. Inaddition, an event message for representing that the content is beingprocessed can be periodically transmitted to the content processingcontroller 41 during the transmission of the content. For example, anevent message including a “ProgressDone” element may be transmitted.When the transmission of the content is completed, the content exporter52 transmits an event message for representing that the transmission ofthe content is completed to the content processing controller 41. Forexample, an event message including a “Completed” element can betransmitted.

When the content starts to be transmitted, the content importer 53 sendsan event message for representing that the content starts to betransmitted to the content processing controller 41. For example, anevent message including a “Started” element may be transmitted. Inaddition, an event message for representing that the content is beingprocessed may be periodically transmitted to the content processingcontroller 41 during the transmission of the content. For example, anevent message including a “ProgressDone” element may be transmitted.When the transmission of the content is completed, the content exporter52 transmits an event message for representing that the transmission ofthe content is completed to the content processing controller 41. Forexample, an event message including a “Completed” element can betransmitted.

When receiving the event message for representing the start oftransmission from the content exporter 52, the content processingcontroller 41 sends the event message corresponding to the start oftransmission to the request client RC1. That is, the content processingcontroller 41 reports that the content starts to be transmitted. Inaddition, when the content processing controller 41 receives the eventmessage for representing that the content is being processed, thecontent processing controller 41 sends the event message correspondingto the processing of the content to the request client RC1. That is, thecontent processing controller 41 reports that the content is beingprocessed. When the content processing controller 41 receives the eventmessage for representing completion of transmission from the contentimporter, the content processing controller 41 sends the event messagecorresponding to the completion of transmission to the request clientRC1. That is, the content processing controller 41 reports that thetransmission of the content is completed. When the aforementioned eventmessages is exported to the request client RC1, the event messagesincluding the transmission session identifier designated when therequest client RC1 requests the content to be transmitted can betransmitted.

On the other hand, the content processing controller 41 separatelyidentifies transmitted contents and reports the transmission status ortransformation status of the contents. Alternatively, the transmittedcontents may be collectively reported. In other words, the contentprocessing controller 41 distinguishes a plurality of contents based onthe transmission time and reports the transmission time to the clientwhenever the content is transmitted. Alternatively, after the contentsare transmitted, the events are collectively managed, and then, thecontent-transmission-status may be reported. In addition, theidentification of the content is performed through the contentidentification information. The aforementioned procedures may besimilarly applied to the license. In case of license, the aforementionedprocedures may be performed by the license transmission controller.

The request client RC1 can recognize the transmission status of thecontent with respect to the session which requests the content to betransmitted, by using the aforementioned method. When a user interfacefunction is included in the request client RC1, the request client RC1may report the transmission status of the content to a user by using anumber or graph.

In addition, when a plurality of contents are transmitted through asession, the transmission status of each content can be recognized.Accordingly, the transmission statuses of contents requested to betransmitted through the session are sequentially recognized.

On the other hand, the content exporter 52, the content transformer 51,and the content importer 53 can recognize an error which occurs in theSAC during transmission of the contents. In this case, the contenthandler which finds the error can transmit the event message forrepresenting that the error occurs to the content processing controller41. For example, an event message including an “Error” or “SAC-Failure”element is transmitted. At this time, the event message surely includesthe transmission session identifier.

When receiving the event message for representing that an error occursfrom a pre-determined content handler, the content processing controller41 requests the content handlers which participate in the transmissionof the contents to cancel the transmission. When the transmission isrequested to be cancelled, the transmission session identifier of thecancelled transmission session has to be provided. In addition, thecontent processing controller 41 sends the event message forrepresenting that the error occurs to the request client RC1.Accordingly, the request client RC1 can recognize that the error occurs.On the other hand, the content handler which receives the request forcanceling transmission cancels the transmission of the session.

The cancellation of the transmission may start by the request clientRC1. In this case, the request client RC1 transmits the request forcancellation of transmission including a transmission session identifierthat is the same as the transmission session identifier provided whenthe content is requested to be transmitted to the content processingcontroller 41. Then, the content processing controller 41 request thecontent handlers which participate in the transmission to cancel thetransmission, in response to the request for cancellation. The contenthandlers which receive the request for cancellation of transmissioncancel the transmission of the session.

On the other hand, the content processing controller 41 may request thecontent transformer 51 to subscribe to an event capable of monitoringthe procedure of transforming the content, in addition to the eventmessage such as the start of the content transmission, the transmissionof the content, the completion of the content transmission, the error ofthe content transmission, and the like and may receive the event messagesuch as the start of the content format transformation, thetransformation of the content format, the completion of the contentformat transformation, the error of the content format transformation,and the like. Selectively, the content processing controller 41 mayrequest the event for representing that the data is transformed througha predetermined encryption technique to be subscribed to and may receivethe event message such as the start of transformation of the datathrough the encryption technique, the transformation of the data throughthe encryption technique, the completion of the transformation of thedata through the encryption technique, the error of the transformationof the data through the encryption technique, and the like. Selectively,the content processing controller 41 may request the transformationcontent handlers to subscribe to the event for representing the SACforming procedure and may receive the event message such as the start offormation of the SAC, the formation of the SAC, the completion of theformation of the SAC, the error of the formation of the SAC, and thelike.

In Example 3-1, the procedures of constructing a content transformationchain with the content processing controller of the processing controlpart and the content handlers of the content processing part andtransmitting a single content or multi contents through a single sessionare described.

In the following Example 3-2, procedures of constructing a plurality ofcontent transformation chains and transmitting a single content or multicontents through multi sessions in response to the request from therequest client RC1 will be described. In this case, the content can betransmitted to one or more destinations, in response to the contenttransmission request.

EXAMPLE 3-2

FIG. 23 is a block diagram illustrating a structure of a system for acontent transmission procedure according to Example 3-2.

Referring to FIG. 23, the request device DV1 may include the requestclient RC1 and the content exporter 52. In addition, a first destinationdevice DV2-1 includes a first content importer 53 a. A seconddestination device DV2-2 includes a second content importer 53 b. Thecontent processing controller 41 and the content transformer 51 areincluded in a device which is separated from the request device DV1 ordestination device DV2.

FIG. 24 is a flowchart illustrating the content transmission procedureaccording to Example 3-2. FIG. 24 illustrates an example of a procedureof transmitting one or more contents included in the request device DV1to the first and second destination devices DV2-1 and DV2-2 which aredestinations, in response to the request of the request client RC1.

As shown in FIG. 24, the request client RC1 transmits the contenttransmission request message for requesting one or more contentsincluded in the request device DV1 to be transmitted to the first andsecond destination devices DV2-1 and DV2-2 to the content processingcontroller 41 (operation S81).

At this time, the content transmission request message includes at leastone transmission session identifier, the content identifier, the sourceinformation, the destination information, and the like. In addition, thecontent transmission request message may include the DRM systeminformation of the destination which receives the content, as an option.

The content identifier may indicate information for identifying thecontent requested to be transmitted. In Example 3-2, since one or morecontents are transmitted to the first and second destination devicesDV2-1 and DV2-2, one or more content identifiers may exist.

The transmission session identifier indicates an identifier for uniquelyidentifying a transmission session. In Example 3-2, the requested one ormore contents have to be transmitted to the first destination deviceDV2-1, and the requested one or more content have to be transmitted tothe second destination device DV2-2. Therefore, the transmission sessionis divided into two transmission sessions. Accordingly, two transmissionsession identifiers may exist. For example, first and secondtransmission session identifiers may exist.

The source information indicates information for determining from wherethe requested content is transmitted. The source information may includean identifier for identifying a source device or system such as therequest device DV1, information on a format of a content file requestedto be transmitted, and the like. In Example 3-2, since the requested oneor more contents are included in the request device DV1, the sourceinformation may include information on the request device DV1 andinformation on a file format.

The destination information includes information for identifying thedestination device DV2 that is the destination to which the requestedcontent is transmitted. The destination information may include adestination identifier for identifying the destination, information on afile format required by the destination, and the like. The informationon the file format included in the destination information can bereferred, when the format transformation of the file is performed by thecontent transformer 51. In Example 3-2, the destination information mayinclude information on the first and second destination devices DV2-1and DV2-2 and format information.

When receiving the content transmission request message, the contentprocessing controller 41 gathers information on the content handlers(operation S82). For example, the content processing controller 41queries one or more content exporters 52, content importers 53, andcontent transformers 51 about the capabilities and obtains responsesfrom the corresponding entities. Accordingly, the capabilities of thesources, midway and destination devices, systems, and DRMs can berecognized.

When information is gathered, the content processing controller 41determines whether the requested one or more contents are transmittedbased on the gathered information. That is, it is checked whether thecontent handlers normally transmit the requested content. Here, it hasto be considered whether the two transmission sessions requested by therequest client RC1 are satisfied.

When the transmission of the content is determined, the contentprocessing controller 41 controls the content handlers so as toconstruct a content transformation chain by determining the contenthandlers which can effectively perform the trans-formation of therequested content. In Example 3-2, since the transmission session fortransmitting the requested content to the first destination device DV2-1is distinguished from the transmission session for transmitting therequested content to the second destination device DV2-2, two contenttransformation chains for performing each transmission session areneeded.

FIG. 25 illustrates a primary content transformation chain fortransmitting one or more contents to a first destination device DV2-1.

As shown in FIG. 25, the primary content transformation chain includesthe content exporter 52, the content transformer 51, and the firstcontent importer 53 a.

FIG. 26 illustrates a secondary content transformation chain fortransmitting one or more contents to a second destination device DV2-2.

As shown in FIG. 26, the secondary content transformation chain includesthe content exporter 52 and the second content importer 53 b.

At this time, the primary content transformation chain includes thecontent transformer 51, but the secondary content transformation chaindoes not include the content transformer 51. Since the format of therequested one or more contents is different from the format of thecontent required by the first destination device DV2-1, the formattransformation of the content is needed. On the other hand, the formatof the requested one or more contents is the same as the format of thecontent required by the second destination device DV2-2.

The content processing controller 41 controls the content handlers so asto construct the primary content transformation chain. The firsttransmission session is performed. Then, the content processingcontroller 41 controls the content handlers so as to construct thesecondary content transformation chain. The second transmission sessionis performed. In another example of constructing the contenttransformation chain, a single session may be repeatedly generated.

First, the content processing controller 41 respectively transmits acontent export request, a content transformation request, and a contentimport request to the content exporter 42, the content transformer 51,and the content importer 53 (operations S84). The aforementionedrequests are performed by transmitting a control message to the contenthandlers.

When the content is requested to be exported, the content processingcontroller 41 can provide the first transmission session identifier, thecontent identifiers of the requested one or more contents, and theinformation on the content transformer 51 which is the receiverinformation to the content exporter 52.

In addition, when the content is requested to be transformed, thecontent processing controller 41 can provide the first transmissionsession identifier, the content identifier of the requested one or morecontents, the information on the content exporter 52 which is thetransmitter information, the information on the content importer 53which is the receiver information, a format of the transmitted one ormore contents, information on a transformed format, and the like.

When the content is requested to be imported, the content processingcontroller 41 can provide the first transmission session identifier, thecontent identifiers of the requested one or more contents, and theinformation on the content transformer 51, which is the transmitter, tothe content exporter 52. In addition, the content processing controller41 can also provide information on a receiver which finally receives thecontent and the DRM information of the destination DRM system. Here, theinformation on the receiver may indicate information on a predeterminedstorage entity or module included in an end-point of transmission of thecontent, for example, the first destination device DV2-1.

As described above, when the content exporter 52, the contenttransformer 51, and the content importer 53 from the content processingcontroller 41 respectively receive the content export request, thecontent transformation request, and the content import request, thecontent is transmitted, and the event is received through the primarycontent transformation chain (operation S85).

First, SACs are established between the content exporter 52 and thecontent transformer 51 and between the content transformer 51 and thefirst content importer 53 a. In addition, a SAC may be also establishedbetween the first content importer 53 a and the first destination deviceDV2-1. When the SACs are established, the content exporter 52 starts totransmit the content. At this time, pairs of the content handlers (thatis, the content exporter 52—the content transformer 51 and the contenttransformer 51—the content importer 53) support the aforementionedmulti-transmission protocol. Accordingly, a plurality of contents can betransmitted through a single session.

A plurality of contents can be transmitted in a session corresponding tothe first transmission session identifier provided by the request clientRC1 (or generated by the content processing controller 41), according tothe support of the multi-transmission protocol. The aforementionedtransmission is sequentially performed from the content exporter 52. Thecontents which are transmitted from the content exporter 52 to thecontent importer 53 via the content transformer 51 may have types ofneutral contents. As described above, a neutral content may indicate aclean content which is not encrypted by using a predetermined DRM.

On the other hand, the content exporter 52, the content transformer 51,and the first content importer 53 a can report the transmission statusof the contents to the content processing controller 41. For this, thecontent processing controller 41 requests the content exporter 52, thecontent transformer 51, and the first content importer 53 a to subscribeto the content-transmission-status event and receives an event message.Since the event is described in Example 3-1, the detailed description onthe event will be omitted.

When the content is transmitted to the first destination device DV2-1(operation S86), the content processing controller 41 transmits acontent export request and a content import request respectively to thecontent exporter 52 and the second content importer 53 b included in thesecondary content transformation chain (operation S87). That is, twocontent transformation chains sequentially perform transmission under acontrol of the content processing controller 41. Surely, the two contenttransformation chains are concurrently generated, and the transmissionis performed by the two content transformation chains under a control ofthe content processing controller.

When the content is requested to be exported, the content processingcontroller 41 can provide the second transmission session identifier,the content identifiers of the requested one or more contents, and theinformation on the content importer 53, which is the receiverinformation, to the content exporter 52. In addition, when the contentis requested to be imported, the content controller 41 can provide thesecond transmission session identifier, the content identifiers of therequested one or more contents, the information on the content exporter52, which is the transmitter, to the second content importer 53 b.

As described above, when the content exporter 52 and the second contentimporter 53 b respectively receives the content export request and thecontent import request from the content processing controller 41, thecontent is transmitted, and the event is received through the secondarycontent transformation chain (operation S88).

First, a SAC is established between the content exporter 52 and thesecond content importer 53 b. When the SAC is established, the contentexporter 52 starts to transmit the content. At this time, a pair of thecontent handlers (that is, the content exporter 52—the second contentimporter 53 b) supports the aforementioned multi-transmission protocol.Accordingly, a plurality of contents can be transmitted through a singlesession.

A plurality of contents can be transmitted through a single sessioncorresponding to the second transmission session identifier provided bythe request client RC1 (or generated by the content processingcontroller 41), according to the support of the multi-transmissionprotocol. The aforementioned transmission is sequentially performed fromthe content exporter 52. The contents which are transmitted from thecontent exporter 52 to the second content importer 53 b may have typesof neutral contents. As described above, a neutral content may indicatea clean content which is not encrypted by using a predetermined DRM.When the neutral content is transmitted to the second content importer53 b included in the second destination device DV2-2, the transmissionis completed (operation S89).

On the other hand, the content exporter 52 and the second contentimporter 53 b can report the transmission status of the content to thecontent processing controller 41. For this, the content processingcontroller 41 requests the content exporter 52 and the second contentimporter 53 b to subscribe to the content-transmission-status event andreceives an event message. The content processing controller 41 canrecognize the transmission status of each content and also provide thetransmission status information to the request client RC1.

In Example 3-2, the procedures of constructing the plurality of contenttrans-formation chains in response to the request of the request clientRC1 and transmitting a single content or multi contents through multisessions are described.

In the following Example 3-3, a case where the content requested by therequest client RC1 is transmitted to a single destination byconstructing a plurality of content transformation chains will bedescribed. In Example 3-3, an example in which two contenttransformation chains are constructed will be described.

EXAMPLE 3-3

FIG. 27 is a block diagram illustrating a structure of a system for acontent transmission procedure according to Example 3-3.

Referring to FIG. 27, the request device DV1 may include the requestclient RC1 and the content exporter 52. In addition, the destinationdevice DV2 includes the content importer 53. The content transmissioncontroller and the content transformer 51 may be included in a deviceseparated from the request device DV1 or the destination device DV2.

FIG. 28 is a flowchart illustrating the content transmission procedureaccording to Example 3-3. FIG. 28 illustrates an example of a procedureof transmitting one or more contents included in the request device DV1to the destination device DV2, which is the destination, in response tothe request of the request client RC1

Referring to FIG. 28, first, the request client RC1 transmits thecontent transmission request message for requesting the content to betransmitted to the content processing controller 41 (operation S100). Atthis time, the content transmission request message includes thetransmission session identifier, the content identifier, the sourceinformation, the destination information, and the like. In addition, thecontent transmission request message may include the DRM systeminformation of the destination which receives the content as an option.

The content identifier may indicate information for identifying thecontent requested to be transmitted. When there are a plurality ofcontents requested to be transmitted, a plurality of content identifiersfor identifying the contents may exist.

The transmission session identifier indicates an identifier for uniquelyidentifying a transmission session. The source information indicatesinformation for determining from where the requested content istransmitted. In Example 3-3, the source information may include theinformation on the request device DV1 and the format information.

The destination information includes information for identifying thedestination device DV2 that is the destination to which the requestedcontent is transmitted. The destination information may include adestination identifier for identifying the destination, information on afile format required by the destination, and the like.

When receiving the content transmission request message, the contentprocessing controller 41 gathers information on the content handlers anddetermines whether the content is to be transmitted, based on thegathered information. When it is determined that the content istransmitted, the content processing controller 41 determines the contenthandlers which participate in the transmission (operations S101 toS103).

First, the content processing controller 41 query one or more contentexporters 52, content importers, and content transformers 51 about thecapabilities and obtain responses from the corresponding entities.Accordingly, the capabilities of the sources, midway and destinationdevices, systems, and DRMs can be recognized.

When information is gathered, the content processing controller 41determines whether the requested content is to be transmitted based onthe gathered information. That is, it is checked whether the contenthandlers normally transmit the requested content. Here, the format ofthe required content, the policy of the system, information on a secureauthenticated channel algorithm which can be executed among entities,and the like may be considered.

When the transmission of the content is determined, the contentprocessing controller 41 determines the content exporter 52 and thecontent transformer 51 and controls the content exporter 52 and thecontent transformer 51 to construct the primary content transformationchain with the content exporter 52 and the content transformer 51. InExample 3-3, an example of a case where the format of the contentrequested to be transmitted is different from the format of the contentrequired by the destination device DV2 is described. Accordingly, thecontent transformer 51 has to be included in the content transformationchain.

FIG. 29 shows an example of a primary content transformation chainconstructed with a content processing controller 41. Referring to FIG.29, the primary content transformation chain includes the contentexporter 52 and the content transformer 51.

Subsequently, the content processing controller 41 sends a contentexport request and a content transformation request respectively to thecontent exporter 52 and the content transformer 51 included in theprimary content transformation chain (operations S107 and S108). Theaforementioned requests are performed by transmitting a control messageto the content handlers.

When the content is requested to be exported, the content processingcontroller 41 can provide the transmission session identifier, thecontent identifier, and the information on the content transformer 51,which is the receiver, to the content exporter 52. In addition, when thecontent is requested to be transformed, the content processingcontroller 41 can provide the transmission session identifier, thecontent identifier, the information on the content exporter 52 which isthe transmitter, the information on the content importer 53 which is thereceiver, a format of the required content, information on a transformedformat, and the like.

As described above, when the content exporter 52 and the contenttransformer 51 respectively receive the content export request and thecontent transformation request from the content processing controller41, a SAC is established between the content exporter 52 and the contenttransformer 51 (operation S109). The content exporter 52 and the contenttransformer 51 can report to the content processing controller that theSAC is established (operations S110 and S111).

When the SAC is established, the content exporter 52 starts to transmitthe content. At this time, each pair of the content handlers (that is,the content exporter 52—the content transformer 51) can support themulti-transmission protocol. As described above, the multi-transmissionprotocol serves to enable multi-contents to be transmitted through asingle session. When a plurality of contents are requested to betransmitted, the plurality of contents may be transmitted through asingle session, according to the support of the multi-transmissionprotocol.

The aforementioned transmission is sequentially performed from thecontent exporter 52. The content exporter 52 transmits the requestedcontent to the content transformer through the SAC. Then, the contenttransformer 51 transforms the format of the content into the requiredformat.

The content exporter 52 and the content transformer 51 can report thetransmission status or transformation status of the content to thecontent processing controller 41. For this, the content processingcontroller 41 has to subscribe to a predetermined event by requestingcontent handlers to provide the predetermined event before requestingthe content to be exported (operations S104 to S106).

The predetermined event may include the content transmission statusproviding event and a content transformation status providing event. Asdescribed above, the content handlers, which participate in thetransmission, can report situations such as the start of the contenttransmission, the transmission of the content, the completion of thecontent transmission, the error of the content transmission, and thelike as the event message by using the content transmission statusproviding event.

The content transformation status providing event can be performed bythe content transformer 51. The content processing controller 41 cansubscribe to the content trans-formation status providing event byrequesting the content transformer 51 to provide the contenttransformation status providing event. Then, the content processingcontroller 41 can be provided with the situations such as the start ofthe content transformation, the transformation of the content, thecompletion of the content transformation, the error of the contenttransformation, and the like

When the content transmitted from the content exporter 52 is transmittedto the content transformer 51, and when the format transformation of thecontent is completed (operation S112), the content processing controller41 has to construct the secondary content transformation chain includingthe content transformer 51 and the content importer 53. The first andsecondary content transformation chains sequentially operate under thecontrol of the content processing controller 41.

FIG. 30 shows an example of a secondary content transformation chainconstructed with a content processing controller 41.

As shown in FIG. 30, the secondary content transformation chain includesthe content transformer 51 and the content importer 53. The contentprocessing controller 41 sends the content transformation request andthe content import request respectively to the content transformer 51and the content importer 53 included in the secondary contenttransformation chain (operations S113 and S114). A SAC is establishedbetween the content transformer 51 and the content importer 53(operation S115). At this time, a SAC may be also established betweenthe content importer 53 and the destination device DV2.

The content transformer 51 transmits the content of which the format istransformed to the content importer 53 through the SAC. Then, thecontent importer 53 receives the transmitted content. The contenttransformer 51 and the content importer 53 can report the transmissionstatus of the content to the content processing controller 41. Thecontent transmitted from the content transformer 51 to the contentimporter 53 is a neutral content. As described above, the neutralcontent may indicate a clean content which is not encrypted by using apredetermined DRM.

In Example 3-3, the procedure of transmitting the content requested bythe request client RC1 to a single destination by constructing twocontent transformation chains is described.

In the following Example 3-4, a case where the content requested by therequest client RC1 is transmitted to a plurality of destinations byconstructing a plurality of content transformation chains will bedescribed.

FIG. 31 is a block diagram illustrating a system for transmitting acontent according to Example 3-4.

Referring to FIG. 31, the request device DV1 may include the requestclient RC1 and the content exporter 52. In addition, the firstdestination device DV2-1 includes the first content importer 53 a. Thesecond destination device DV2-2 includes the second content importer 53b. A third destination device DV2-3 includes a third content importer 53c. The content transmission controller and the content transformer 51may be included in a device separated from the request device DV1 or thedestination device DV2.

FIG. 32 is a flowchart illustrating a content transmission procedureaccording to Example 3-4. FIG. 32 illustrates an example of a procedureof transmitting a content included in the request device DV1 to thefirst to third destination devices DV2-1 to DV2-3, which are threedestinations, in response to the request of the request client RC1.

Referring to FIG. 32, the request client RC1 transmits the contenttransmission request message for requesting the content to betransmitted to the content processing controller 41 (operation S121). Atthis time, the content transmission request message includes thetransmission session identifier, the content identifier, the sourceinformation, the destination information, and the like. In addition, thecontent transmission request message may include the DRM systeminformation of the destination which receives the content, as an option.

The content identifier may indicate information for identifying thecontent requested to be transmitted. When there is a plurality ofcontents requested to be transmitted, a plurality of content identifiersfor identifying the contents may exist.

The transmission session identifier indicates an identifier for uniquelyidentifying a transmission session. The source information indicatesinformation for determining from where the requested content istransmitted. In Example 3-4, the source information may includeinformation on the request device DV1 and format information.

The destination information includes information for identifying thedestination device DV2 that is the destination to which the requestedcontent is transmitted. In Example 3-4, the destination information mayinclude information on the first to third destination devices DV2-1 toDV2-3, format information required by the destination devices DV2, andthe like. In Example 3-4, the file formats required by the first tothird destination devices DV2-1 to DV2-3 are assumed to be the same.However, the present invention is not limited thereto.

When receiving the content transmission request message, the contentprocessing controller 41 gathers information on the content handlers(operation S122). For example, the content processing controller 41queries one or more content exporters 52, content importers 53, andcontent transformers 51 about the capabilities and obtains responsesfrom the corresponding entities. Accordingly, the capabilities of thesources, midway and destination devices, systems, and DRMs can berecognized.

When information is gathered, the content processing controller 41determines whether the requested one or more contents are transmitted,based on the gathered information. That is, it is checked whether thecontent handlers normally transmit the requested content. Here, theformat of the required content, the policy of the system, information ona secure authenticated channel algorithm which can be executed amongentities, and the like may be considered.

When the transmission of the content is determined, the contentprocessing controller 41 controls the content exporter 52 and thecontent transformer 51 so as to construct the primary contenttransformation chain including the content exporter 52 and the contenttransformer 51. In Example 3-4, an example of a case where the format ofthe content requested to be transmitted is different from the format ofthe content required by the destination device DV2 is described.Accordingly, the content transformer 51 has to be included in thecontent transformation chain. In the present description, a chain isconstructed by receiving a control command for constructing the contenttransformation chain from the client. However, the present invention isnot limited thereto. There are various embodiments such as an example inwhich the content processing controller may generate a control commandfor constructing a chain and construct the chain.

FIG. 33 illustrates an example of a primary content transformation chainconstructed with a content processing controller 41. Referring to FIG.33, the primary content transformation chain includes the contentexporter 52 and the content transformer 51.

Subsequently, the content processing controller 41 sends a contentexport request and a content transformation request respectively to thecontent exporter 52 and the content transformer 51 included in theprimary content transformation chain (operation S124). Theaforementioned requests are performed by transmitting a control messageto the content handlers.

When the content is requested to be exported, the content processingcontroller 41 can provide the transmission session identifier, thecontent identifier, and the information on the content transformer 51,which is the receiver, to the content exporter 52. In addition, when thecontent is requested to be transformed, the content processingcontroller 41 can provide the transmission session identifier, thecontent identifier, the information on the content exporter 52 which isthe transmitter, the information on the content importer 53 which is thereceiver, a format of the required content, information on a transformedformat, and the like.

As described above, when the content exporter 52 and the contenttransformer 51 respectively receive the content export request and thecontent transformation request from the content processing controller41, a SAC is established between the content exporter 52 and the contenttransformer 51.

When the SAC is established, the content exporter 52 starts to transmitthe content (operation S125). At this time, each pair of the contenthandlers (that is, the content exporter 52—the content transformer 51)can support the multi-transmission protocol. Since themulti-transmission protocol is supported, when a plurality of contentsare requested to be transmitted, the plurality of contents may betransmitted through a single session.

The aforementioned transmission is sequentially performed from thecontent exporter 52. The content exporter 52 transmits the requestedcontent to the content transformer through the SAC. Then, the contenttransformer 51 transforms the format of the content into the formatrequired by the destination device DV2 (operation S126).

The content exporter 52 and the content transformer 51 can report thetransmission status or transformation status of the content to thecontent processing controller 41. For this, the content processingcontroller 41 has to subscribe to a predetermined event by requestingcontent handlers to provide the predetermined event before requestingthe content to be exported. At this time, the predetermined event mayinclude the content transmission status providing event and a contenttransformation status providing event. Since this is described inExample 3-3, the detailed description will be omitted.

When the content transmitted from the content exporter 52 is transmittedto the content transformer 51, and when the format transformation of thecontent is completed, the content processing controller 41 sequentiallyconstructs a plurality of secondary content transformation chainscorresponding to the plurality of destinations. The plurality ofsecondary content transformation chains may include first to thirdsecondary content transformation chains. Here, the first to thirdsecondary content transformation chains may be sequentially orconcurrently formed. In addition, the method of constructing contenttransformation chains may include a method of forming a chain from astarting point to a destination and repeatedly forming the chain (aplurality of single chains are constructed as described in Example 3-2)or a method of separately forming chains by distinguishing the chainsbased on transformation times (described in Examples 3-3 and 3-4). Also,a plurality of transmission session identifiers are required fortransmitting data through a plurality of secondary chains. Thesetransmission session identifiers may be generated in the client orcontent processing controller 41, or the content transformer 51.

FIG. 34 illustrates an example of structures of a first secondarycontent trans-formation chain, a second secondary content transformationchain, and a third secondary content transformation chain induced by acontent processing controller 41.

As shown in FIG. 34, the first secondary content transformation chainmay include the content transformer 51 and the first content importer 53a. The content trans-formation controller transmits the contenttransformation request and the content import request respectively tothe content transformer 51 and the first content importer 53 a. An SACis established between the content transformer 51 and the first contentimporter 53 a. When the SAC is established, the content is transmittedfrom the content transformer 51 to the first content importer 53 a(operation S127).

When the content is transmitted to the first content importer 53 a, thecontent processing controller 41 constructs the second secondary contenttransformation chain. At this time, the second secondary contenttransformation chain may include the content transformer 51 and thesecond content importer 53 b. The content trans-formation controllertransmits the content transformation request and the content importrequest respectively to the content transformer 51 and the secondcontent importer 53 b. Then, a SAC is established between the contenttransformer 51 and the second content importer 53 b. When the SAC isestablished, the content is transmitted from the content transformer 51to the second content importer 53 b (operation S128).

When the content is transmitted to the second content importer 53 b, thecontent processing controller 41 constructs the third secondary contenttransformation chain. At this time, the third secondary contenttransformation chain may include the content transformer 51 and thethird content importer 53 c. The content transformation controllertransmits the content transformation request and the content importrequest respectively to the content transformer 51 and the third contentimporter 53 c. Then, when the SAC is established, the content istransmitted from the content transformer 51 to the third contentimporter 53 c (operation S129).

On the other hand, the content handlers included in the secondarycontent trans-formation chain can transmit the event message forrepresenting the transmission status of the content and the like to thecontent processing controller 41 according to the progress of thetransmission process. The aforementioned event has been described inExamples 3-1 to 3-3.

In Example 3-4, the procedure of transmitting the content requested bythe request client RC1 to the plurality of destination devices DV2 byconstructing the plurality of content transformation chains isdescribed. In the method of transmitting the content according toExample 3-4, it is possible to broadcast a content to a plurality ofdestinations and reduce waste of transmission resources. It is possibleto reduce the number of format transformation operations of the contentperformed so as to transmit the content to the plurality ofdestinations. Even though an error occurs in the secondary contenttransformation chain, the operation of the primary contenttrans-formation chain is already performed, and therefore, only thesecondary content trans-formation chain has to be recovered.

4. Functions and Operations of the Processing Control Part and theLicense Processing Part

On the other hand, the authenticated client of the client part canrequest the processing control part to transmit a license. For example,it is assumed that there are a first client device in which a first DRMis installed and a second client device in which a second DRM isinstalled. When a user intends to transmit a first DRM content stored inthe first client device to the second client device, the first clientcan transmission the content to the second client device which is thedestination, by using the aforementioned procedures of transmitting thecontent. In this case, when the second client device intends to use thetransmitted content, a license suitable for the second DRM is required.Accordingly, the first client requests the license to be transmitted.

FIG. 35 is a block diagram illustrating a structure of a system relatedto a transmission of a license.

As shown in FIG. 35, the processing control part 40 includes the contentprocessing controller 41 and the license processing controller 42. Here,the content processing controller 41 has been described before. Thecontent processing controller 41 and the license processing controller42 may be included in any place in the network area or local area. Thecontent processing controller 41 and the license processing controller42 may be located in different areas. For example, the contentprocessing controller 41 may be included in a predetermined device inthe local area. The license processing controller 42 may be included ina service provider in the network area. The locations of the contentprocessing controller 41 and the license processing controller 42 arenot limited.

The license processing controller 42 receives a license transmissionrequest from a client. When receiving the license transmission request,the license processing controller 42 determines the entities whichparticipate in the transmission and determines whether the license canbe transmitted, by gathering information on entities included in thesystem. Accordingly, a chain through which the license is transmittedmay be constructed.

The license manager 24 of the authentication and management part 20 anda license processor 32 of the license processing part 30 in addition tothe license processing controller 42 can participate in the transmissionof the license. The entities which participate in the transmission ofthe license may be included in any place in the network area or localarea. SACs for security of the transmitted license information may beestablished among predetermined entities, at need.

The license processing controller 42 requests a predetermined entity,for example, the license manager 24 to provide one or more neutrallicenses and receives the one or more neutral licenses. The neutrallicense may indicate compatible neutral license information from whichlicense information of many types of DRMs can be extracted. When a userpurchases a predetermined DRM content, the neutral license may begenerated and stored in the license manager by using the license of theDRM. The neutral license 24 may be stored in the domain manager orreference point controller in addition to the license manager 24. In theprocedure of transmitting a license, the entity which provides theneutral license may perform the function of the exporter.

The neutral license may include one or more related content identifiers,manager information, information on a subject which can use the license,usage models in which limitations of authority are described, and thelike.

The license processing controller 42 generates a new neutral license tobe practically transmitted by using the provided neutral license. Atthis time, various types of information such as the relation between thecontent and the subject, the destination, a mapping relation of thesubject, a resource mapping relation, and the like can be considered.

The neutral license generated by the license processing controller 42 istransmitted to the license processor 32 of the license processing part30. The license processor 32 is an entity which transmits the neutrallicense received form the license processing controller 42 to a nativeDRM receiver 900 of the destination. At this time, the license processor32 may transform the received neutral license into the license suitablefor the DRM of the destination and provide the transformed license tothe native DRM receiver 900 by obeying the method defined in the DRM ofthe destination. Alternatively, the neutral license may be provided tothe native DRM receiver 900 of the destination as it is. In this case,the license transformation is performed in the DRM system of thedestination. The license processor and the native DRM receiver mayrespectively perform the functions of the transformer and the receiver.

The entities which participate in the transmission of the license cantransmit an event message for representing the procedures oftransmitting and processing the license to the license processingcontroller 42. For this, the license processing controller 42 has tosubscribe to the license transmission status event by requesting thecorresponding entity to provide the license transmission status event.The license processing controller 42 may provide informationcorresponding to the received event message to the client 3. Inaddition, the license processing controller 42 may provide an eventmessage for representing a progress status such as the procedure ofgenerating the neutral license and the procedure of providing theneutral license from the license manager 24 to the client.

Up to now, main functions of the DRM interoperable system including theclient part 10, the authentication and management part 20, theprocessing control part 40, the content processing part 50, and thelicense processing part 30 are described. In the aforementioneddescription, the DRM interoperable system according to an exemplaryembodiment of the present invention allows the neutral data (neutralformat content or neutral license) to be compatible with the formatrequired by the destination and transmits the neutral data to thedestination, in response to the data (content or license) transmissionrequest from the client.

5. Functions of Unit Entities and Procedures of Processing Events

Each part of the DRM interoperable system such as the client part 10,the authentication and management part 20, the processing control part40, the content processing part 50, the license processing part 30, andthe like is constructed with one or more entities. At this time, theentities may indicate modules or devices constructed as software orhardware which perform predetermined unique functions. Each entity maybe constructed with one or more unit function modules which performpre-determined unit functions. The entity is installed in apredetermined device to communicate data with other entity through apredetermined interface. In addition, even though the entities belong tothe same part, the entity may be installed in different devices. Thedevices may be different according to execution environments.

When the domain is initially constructed, the entity can report theexistence of the entity to another entity in a particular environment inwhich the entity is included. For this, the entity may include aconstruction information provider which is a unit function module.

FIG. 36 shows an example for illustrating unit function modules includedin an entity and functions of the unit function modules.

As shown in FIG. 36, a predetermined entity 110 includes a plurality ofunit function modules 111 which perform unique unit functions and aconstruction information provider 112. The construction informationprovider 112 has to provide construction information of thepredetermined entity 110 in response to the request for providing theconstruction information from the request entity which is anotherentity. At this time, the construction information may includeinformation on the unit function module 111 included in thepredetermined entity 110.

In addition, the construction information provider 112 can be requestedby another entity to subscribe to a construction information changeevent. Then, the construction information provider 112 permits or doesnot permit the subscription by determining whether the subscriptionrequest is legal. At this time, the construction information changeevent may represent the event message including the change of theconstruction information of the predetermined entity 110, when theconstruction information of the predetermined entity 110 changes.

The construction information change event may be provided in a push orpull manner. In the push manner, the construction information provider112 pushes the event message including the changed constructioninformation to the request entity 114 which subscribes to the event,whenever the construction information of the pre-determined entity 110changes. In the pull manner, the request entity 114, which subscribes tothe event, obtains the changed construction information of thepre-determined entity 110 at need. When the request entity 114 requeststhe event to be subscribed to, it is reported to the constructioninformation provider 112 whether the event message is transmitted in thepush or pull manner. Accordingly, it is set whether the event message istransmitted in push or pull manner.

There are various types of events such as the aforementioned contenttrans-formation status event, the construction informationtransformation event, and the like, in addition to the constructioninformation change event. Hereinafter, a procedure of performing anevent among the entities will be described.

FIG. 37 shows an example for illustrating a procedure of transmitting anevent between two authenticated entities.

As shown in FIG. 37, an entity having a function of an event subscriberand an entity having an event issuing function have to exist so as toperform a predetermined event. Hereinafter, the entity having thefunction of the event subscriber is referred to as an event subscriptionentity 117. The entity having the event issuing function is referred toas an event issuing entity 119. In addition, the events may have eventtitles. An event title is information for representing which event amongthe content transmission status event, the construction informationtransformation event, and the like is the event.

The event issuing entity 119 has to have a unique identifier of its own.This is because the event issuing entity 119 can be distinguished fromanother event which performs an event having the same event title as theevent performed by the event issuing entity 119. The unique identifierof the event issuing entity 119 may include a factor for representingsources of the event messages issued by the event issuing entity 119.

In order to subscribe to a predetermined event, the event subscriptionentity 117 has to request the event issuing entity 119 which issues thepredetermined event to subscribe to the event.

When the event is requested to be subscribed to, the event subscriptionentity 117 provides the unique identifier for allowing the event issuingentity 119 to identify the event subscription entity 117. In addition,the event subscription entity 117 has to report to the event issuingentity 119 whether the event provided by the event issuing entity 119 isprovided in the push or pull manner. Accordingly, it is set whether theevent is provided in push or pull manner. At this time, in the pushmanner, the event issuing entity 119 automatically pushes the eventmessage including the corresponding information into the eventsubscription entity 117, whenever the event condition occurs. On theother hand, in the pull manner, the event subscription entity 117queries the event issuing entity 119 and obtains the event message, atneed.

In addition, the event subscription entity 117 may provide an eventsubscription ID, expiration information, a structure of the eventinformation desired to be provided, and the like to the event issuingentity 119. The expiration information may indicate a subscriptionexpiration value of the event. For example, the expiration informationmay include an expiration data, subscription period of the event, andthe like. When the expiration information is not provided, thesubscription period is not limited.

The event issuing entity 119 permits or does not permit the subscriptionby determining whether the event subscription request is valid, inresponse to the event subscription request. At this time, responsemessage including information for indicating permission on subscriptionand information for representing nonpermission on subscription istransmitted to the event subscription entity 117 in correspondence withthe determination result.

In the determination, the event subscription ID, the expirationinformation, and the like may be considered. For example, in a casewhere the event subscription ID is provided by the event subscriptionentity 117 when the event is requested to be subscribed to, the eventissuing entity 119 can consider whether the event subscription ID isvalid and whether the event subscription ID is expired. At this time,when the event subscription ID provided by the event subscription entity117 is not valid or expired, the event issuing entity 119 can transmitthe message for indicating non-permission on the subscription to theevent subscription entity 117. Alternatively, when the eventsubscription ID provided by the event subscription entity 117 is validand not expired, the subscription ID and the information on thesubscription ID can be used. On the other hand, in a case where theevent subscription ID is not provided by the event subscription entity117 when the event is requested to be subscripted to, the event issuingentity 119 can provide a new event subscription ID.

On the other hand, the event subscription entity 117 can cancel thecurrent subscription of the event. For this, the event subscriptionentity 117 can send the message for indicating the cancellation of theevent to the event issuing entity 119. In addition, the eventsubscription entity 117 may stop the subscription of the event bycanceling the set method of providing the event. For example, in themethod of providing the event currently selected as the push or pullmanner so as to subscribe to the event, selection of the push and pullmanners is cancelled.

Up to now, the construction information among entities and the method ofprocessing the event have been described. Through the aforementionedmethod, it is possible for entities to interact with one anotheraccording to specific situations.

6. Method and Infra-System for Managing a Domain

Hereinafter, a method and an infra-system for managing a domain capableof managing movement of a domain location will be described. For this,current and previous locations of the domain can be stored and managedby using the domain manager which manages the domain. In addition, themovement of the domain location may be limited according topredetermined limitations.

The DRM interoperable system manages information on the movement of thedomain location. Specifically, the DRM interoperable system limits themoved location of the domain or the number of movements. When it isfound that the domain is formed out of the limited range by checking thelocation change of the domain, the DRM interoperable system destroys thedomain or performs an additional action.

Hereinafter, a method of managing the domain capable of managing thelocation movement information of the domain will be described. Anembodiment of the method of managing the domain to be described mayinclude a method of limiting the number of movements of the domain, amethod of limiting a formation location of the domain, and the like. Forconvenience of understanding, the former is referred to as Example 4-1,and the latter is referred to as Example 4-2. In addition, the basis ofthe systems of Examples 4-1 and 4-2 is illustrated in FIG. 2.

EXAMPLE 4-1

FIG. 38 is a flowchart illustrating a method of managing a domainaccording to Example 4-1. FIG. 38 illustrates procedures of setting thepermitted number Na of movements of the domain corresponding to logininformation, checking the number of the movements of the domain, andlimiting the formation of the domain.

The domain manager 22 stores the permitted number Na of movements of thedomain corresponding to the login information. The login information maybe received from the license manager 24. Alternatively, the domainmanager 22 may provide a login function. The permitted number Na ofmovements of the domain may depend on costs paid by a user. The upperlimit of the number may be politically set by a service provider. Thepermitted number Na of the movements of the domain may be set as five,ten, and the like. In addition, the domain manager 22 stores and managesthe current and previous locations of the domain. When the domain moves,the domain manager 22 stores and manages the number of movements.

Referring to FIG. 38, the domain manager 22 examines the currentlocation of the domain 5 (operation S140) and determines whether thedomain moves (operation S141). Specifically, it is determined whetherthe domain moves by comparing the current location of the domain withthe location of the domain obtained from the previous examination. Thedetermination may be performed every predetermined period. Selectively,the determination may be performed whenever a new domain is formed.Selectively, the determination may be arbitrarily performed depending onmonitoring of the service provider.

The reference point controller 26 in the domain 5 can participate in thedetermination of the location of the domain 5. At this time, thereference point controller 26 may be a reference point with respect tothe formation location of the local domain. The reference pointcontroller 26 may be included in a predetermined device that subscribesto the domain 5 in the local area. The reference point controller 26reports the information on the inside of the domain 5, for example, theinformation on the location of the domain 5 to the domain manager 22 asa representative of other client devices in the domain.

Alternatively, the reference point controller 26 may not participate inthe determination of the location of the domain 5. Each device mayprovide the information on the location in the domain by accessing thedomain manager 22. That is, the reference point controller 26 mayparticipate or not participate in the determination of the location ofthe domain. This is a selective factor according to executionenvironments.

Accordingly, the location of the domain 5 may indicate the location ofthe reference point controller 26 in the domain or the location of eachdevice. On the other hand, it is possible to improve security bylimiting the number of selections of the reference point controllerincluding the reference point controller 26 to the pre-determinednumber. In addition, the user may login through the reference pointcontroller 26.

Methods of determining the location of the domain will be described inthe following.

In a first method, the location of the domain can be determined by usingan IP address of the reference point controller 26. In this case, thefirst method can be performed in a model to which a high-speed internetprovider allocates a fixed IP.

In a second method, the location of the domain can be determined byusing an IP subnet address of the reference point controller 26. Forexample, when the subnet address is the same as the previously detectedsubnet address, it is considered that the domain does not move. When thesubnet address is changed and when TTL is not within three hops, it isconsidered that the domain moves.

In a third method, when the domain enters a neighboring area of thereference point controller 26, the location of the domain is recognizedby using a media access control (MAC) address of the reference pointcontroller 26. For example, when a set-top box, which is considered as aseparate reference point controller by a high-speed internet provider,is installed in a house, the periphery of the set-top box is set as thedomain. A device connected to the set-top box in a wired or wirelessmanner is recognized that the device enters in a predetermined domain.Accordingly, the location of the device can be designated.

In a fourth method, the location of the domain can be determined byusing a global positioning system (GPS).

In a fifth method, in case of a mobile terminal such as a mobile phone,the location of the device in the domain can be determined by a basestation.

On the other hand, when it is determined that the domain moves, thedomain manager 22 increase the previous number of movements of thedomain by 1 (operation S142) and identifies the total number N ofmovements of the domain, which has been increased up to now (operationS143). Alternatively, when the domain does not move, the currentlyformed domain 5 is maintained (operation S147).

Subsequently, the domain manager 22 compares the current total number Nof movements of the domain with the stored permitted number Na ofmovements of the domain (operation S144). When as a result ofcomparison, it is determined that the total number N of movements of thedomain is equal to or less than the permitted number Na of movements ofthe domain, the domain manager 22 maintains the current domain 5(operation S147). Alternatively, when the total number N of movements ofthe domain is greater than the permitted number Na of movements of thedomain, the domain manager 22 prohibits the use of the current domain(operation S145).

Next, the domain manager 22 records a history of service stops withrespect to the current user (operation S146). Additionally, the domainmanager reports information on the domain destruction to the serviceprovider. The service provider or domain manager 22 may transmit awarning message to the user. In addition, the service provider or domainmanager 22 induces the user to purchase new domain login informationthrough a consumer payment system.

On the other hand, the accumulated number of movements of the domain maybe reset every period according to a policy of the service provider. Forexample, the number of movements of the domain may be annually reset.

EXAMPLE 4-2

FIG. 39 is a flowchart illustrating a method of managing a domainaccording to Example 4-2. FIG. 39 illustrates a procedure of limitinggeneration of a domain by checking a formation location of the domain.

For this, the domain manager 22 stores the permitted number Ma of domainlocations corresponding to login information. The permitted number Ma ofthe domain locations may depend on costs paid by a user. The upper limitof the number may be politically set by a service provider. Thepermitted number Ma of the domain locations may be set as five, eight,and the like. In addition, the domain manager 22 stores and manages thecurrent and previous locations of the domain.

Referring to FIG. 39, the domain manager 22 examines the currentlocation of the domain 5 (operation S150) and determines whether thedomain moves (operation S151). Specifically, it is determined whetherthe domain moves by comparing the current location of the domain withthe location of the domain obtained from the previous examination. Thedetermination may be performed every predetermined period. Selectively,the determination may be performed whenever a new domain is formed.Selectively, the determination may be arbitrarily performed depending onmonitoring of the service provider.

As described above, the reference point controller 26 may participate ormay not participate in the determination of the location of the domain5. The location of the domain 5 can be determined by using the IPaddress, the IP subnet address, the MAC information of the referencepoint controller 26, the GPS, mobile communication information, and thelike.

When it is determined that the domain does not move, the domain manager22 maintains the current domain 5 (operation S158). On the other hand,when it is determined that the domain moves, the domain manager 22determines whether the current location of the domain is a new locationby comparing the current location of the domain 5 with the storedprevious locations of the domain (operation S152).

When it is determined that the current location of the domain is not anew location, the domain manager 22 maintains the current domain 5(operation S158). On the other hand, when the current location of thedomain is a new location, the domain manager 22 stores the currentlocation of the domain (operation S153).

Subsequently, the domain manager 22 obtains the total number M of domainformation locations including the current location of the domain 5(operation S154) and compares the obtained number M with thepredetermined permitted number Ma of domain locations (operation S155).As a result of comparison, when it is determined that the total number Mof the domain formation locations is equal to or less than the permittednumber Ma of domain locations, the domain manager 22 maintains thecurrent domain 5 (operation S156). Alternatively, when the total numberM of the domain formation locations is greater than the permitted numberMa of domain locations, the domain manager 22 destroys the currentdomain 5 (operation S157).

Next, the domain manager 22 records a history of service stops withrespect to the current user. Additionally, the domain manager reportsinformation on the domain destruction to the service provider. Theservice provider or domain manager 22 may transmit a warning message tothe user.

As described above, in Example 4-2, the domain manager 22 limitsformation of the domain according to formation locations of the domain.For example, when the service provider permits four domain formationlocations, the domain manager 22 automatically memorizes the fourlocations of the domain from the first location of the domain anddetermines whether the subsequent formation location of the domaindeviates from the permitted four locations. When the domain is formedonly at the memorized locations, although the domain frequently moves,the movement of the domain is not limited. Alternatively, when thedomain moves to another place except the four memorized locations, thedomain manager 22 limits the formation of the domain.

On the other hand, in a case where an action range of the user iscompletely changed, for example, the user moves into a new house, whenthe location of the domain is mismatched with the previous location ofthe domain, the domain formation location needs to be newly stored basedon the moved location except the domain formation location firstlymemorized by the domain manager 22. In this case, the information on thedomain formation location may be newly reset in response to the specificrequest of the user.

In addition, the information on the domain formation location may bereset by a policy of the service provider. In this case, the number ofthe resets may be limited. For example, the number of the resets of theinformation on the domain formation location may be limited to one ortwo per year. On the other hand, the change of the information on thedomain formation location can be defined by using a service subscriptioncontents and service login information in addition to a change of an IPaddress.

Up to now, the method of managing a domain capable of storing andmanaging current and previous locations of the domain and limiting thenumber of movements of the domain based on predetermined limitations isdescribed.

7. Structure, Operation, and Scenario for Preventing Misuse andContamination of a Content

When non-reliable contents, for example, improper contents orcontaminated contents, and the like are introduced into environments ofsharing contents among different types of DRMs through the DRMinteroperable system, a user or system may be exposed to the harm. Asystem and a scenario capable of coping with the harm are required.

Hereinafter, a method of processing a content by using a DRMinteroperable system, in which suitable actions can be prepared bychecking whether the externally introduced content is misused,contaminated, and applied with a security function, will be described.

FIG. 40 is a block diagram illustrating a structure of a system of anenvironment in which different types of DRMs are compatible with eachother.

As shown in FIG. 40, a DRM interoperable system 340 provides a DRMinteroperable function so that predetermined DRM areas, for example,first and second DRM areas 320 and 330 are compatible with each other.In FIG. 34, a case where two DRM areas are compatible with each other byusing the DRM interoperable system is described. The present inventionis not limited thereto. Three or more DRM regions may be compatible withone another by using the DRM interoperable system.

The first DRM region 320 may indicate a DRM protection area including asystem or device which uses a first DRM employed by a first serviceprovider 322.

The first DRM area 320 may include a first DRM system 323. The first DRMsystem 323 serves to generate a first DRM content and a first license,which is authority information for using the first DRM content byapplying the first DRM to a source content provided by the first contentprovider 322 and provide the generated first DRM content and the firstlicense to the first client device 210. At this time, the first clientdevice 210 may indicate a device in which the first DRM is installed.Accordingly, the first client device 210 can use the first DRM contentin the authority range allowed by the first license. In FIG. 40, thefirst content provider 325 is separated from the first service provider322. However, the present invention is not limited thereto. The firstcontent provider 325 may be the same as the first service provider 322.Alternatively, the first content provider 325 may be included in thefirst service provider 322.

The first DRM system 323 may interact with a first security system 325.The first security system 324 is used to apply a security function tothe first DRM content. For example, the system may be a fingerprintingsystem which provides a tracking function for tracking a user who uses acontent, a watermarking system for protecting copyright of an author, ananti-virus system for checking and curing virus contamination of thecontent, a misuse prevention system for preventing possibility of themisuse of the content, or an intrusion detection system (IDS).

The second DRM area 330 uses a DRM that is different from that of theaforementioned first DRM area 320. That is, the second DRM area 330 mayindicate a DRM protection area including a system or device using thesecond DRM employed by the second service provider 332.

The second DRM area 330 may include a second DRM system 333. The secondDRM system 333 serves to generate a second DRM content and a secondlicense, which is authority information for using the second DRM contentby applying the second DRM to a source content provided by the secondcontent provider 335 and provide the generated second DRM content andthe second license to the second client device 331. At this time, thesecond client device 331 may indicate a device in which the second DRMis installed. Accordingly, the second client device 331 can use thesecond DRM content in the authority range allowed by the second license.In FIG. 40, the second content provider 335 is separated from the secondservice provider 332. However, the present invention is not limitedthereto. The second content provider 335 may be the same as the secondservice provider 332. Alternatively, the second content provider 335 maybe included in the second service provider 332.

The second DRM system 333 may interact with a second security system334. The second security system 333 is a system for applying a securityfunction to the second DRM content. For example, the system may be awatermarking system, a fingerprinting system, an anti-virus system, amisuse prevention system, or an IDS.

FIG. 41 is a block diagram illustrating a detailed structure of a DRMarea. The structure of the DRM area shown in FIG. 41 can be commonlyapplied to the structure of the first or second DRM area 320 or 330shown in FIG. 40.

Referring to FIG. 41, a content provider 380 provides a content having araw data type or a content to which a predetermined security functionsuch as a watermark is applied to a DRM system 371.

A DRM server 372 of the DRM system 371 encrypts the provided content byusing an encryption module and transmits a secret key value used toencrypt the content and the license information together with theencrypted content to a client device 360. The license information may beprovided by a license server 375. A client DRM module 361 of the clientdevice 360, which receives the encrypted content, recovers the contentby decrypting the encrypted content.

In addition, fingerprinting information may be inserted into the contentto be transmitted to the client device 360. The insertion of thefingerprint information is performed by a fingerprinting system 376included in the service provider 370. The fingerprinting system 376 mayinclude a fingerprinting code generator 377, an inspector 378, afingerprinting engine 379, and the like. The fingerprinting informationfor identifying a user of the client device 360 may be inserted into thecontent transmitted to the client device 360. The insertion of thefingerprinting information may be performed by the fingerprinting engineincluded in the client device 360.

In FIG. 41, an example in which a fingerprinting function is applied toa content is illustrated. However, the security function which can beapplied to the content may be the aforementioned watermarking function,misuse prevention function, or IDS function.

As shown in FIGS. 40 and 41, a security system for applying the securityfunctions to the content such as a fingerprinting system, a watermarkingsystem, an anti-virus system, a misuse prevention system, an IDS, andthe like may be installed in the service provider of the DRM area.Alternatively, the security system may be included in the DRMinteroperable system.

FIG. 42 is a block diagram illustrating a structure of a DRMinteroperable system. FIG. 42 illustrates a case where the DRMinteroperable system includes a function of securing reliability of anexternally introduced content.

As shown in FIG. 42, the DRM interoperable system may further include asecurity system 9 and a content reliability management part 8. Asdescribed above, the security system 9 may indicate a fingerprintingsystem, a watermarking system, an anti-virus system, a misuse preventionsystem, or an IDS. The security system 9 may be included in a DRMinteroperable system 500. Alternatively, the DRM interoperable system500 may interact with another security system.

The content reliability management part 8 can interact with an externalnative DRM area and includes various processes for securing reliabilityof the content. When a content is externally requested to be introduced,the process of the content reliability management part 8 may beautomatically performed. Alternatively, the process may be performed inresponse to a request of the processing control part. The process of thecontent reliability management part 8 will be described according to thefollowing scenario.

Hereinafter, when a content is transmitted in the DRM interoperableenvironment, scenarios in which the reliability of the content can besecured will be described. At this time, in the DRM interoperableenvironment, a content can be transmitted from a predetermined DRM areato a target DRM area via the DRM interoperable system.

First, in the following description, there are sequentially described ascenario to which a misuse prevention policy can be applied when a DRMcontent is transmitted, a scenario which can prevent the contentcontaminated by viruses from spreading when the DRM is allowed to becompatible with another DRM, a scenario to which a watermarking functioncan be applied when the DRM is allowed to be compatible with anotherDRM, another scenario to which a watermarking function can be appliedwhen the DRM is allowed to be compatible with another DRM, a scenario towhich a fingerprinting function can be applied when the DRM is allowedto be compatible with another DRM, another scenario to which afingerprinting function can be applied when the DRM is allowed to becompatible with another DRM, and a processing scenario used when a userof which fingerprint information is not matched with stored informationrequests a content to be transmitted. For convenience of understanding,the first scenario is referred to as Example 5-1. The second scenario isreferred to as Example 5-2. The third scenario is referred to as Example5-3. The fourth scenario is referred to as Example 5-4. The fifthscenario is referred to as Example 5-5. The sixth scenario is referredto as Example 5-6. The seventh scenario is referred to as Example 5-7.

EXAMPLE 5-1

FIG. 43 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-1. FIG. 43 illustrates a procedure to which a content misuseprevention policy can be applied when a DRM content is transmitted in aDRM interoperable environment.

The misuse prevention policy is designed to prevent a case where a DRMcontent is improperly used. For example, the misuse prevention policymay include a policy which previously prevents an infant from watchingan adult content that cannot be used by a user under the age of 19.

As shown in FIG. 43, the DRM interoperable system 500 receives a contentrequest message for requesting a predetermined content to be transmittedfrom a first client device 410 included in a first DRM area to a secondclient device 610 included in a second DRM area 600 (operation S170).The content transmission request message may include the contentrequested to be transmitted, information on a transmitter whichtransmits the content, information on a receiver which receives thecontent, and the like. At this time, since the requested content istransmitted from the first client device 410 included in the first DRMarea 400, the requested content may indicate a content to which thefirst DRM is applied.

When receiving the request for transmitting the content, the DRMinteroperable system 500 extracts transmitter information and receiverinformation from the received content transmission request message(operation S171). Subsequently, the DRM interoperable system 500requests a predetermined entity of the first DRM area 400 to providetransmission user information corresponding to the extracted transmitterinformation (operation S172) and requests a predetermined entity of thesecond DRM area 600 to provide receiving user information correspondingto receiver information (operation S173).

At this time, the predetermined entity of the first DRM area 400 may bea first service provider 420. The predetermined entity of the second DRMarea 600 may be a second service provider 620. Then, the first andsecond service providers 420 and 620 provide the transmission userinformation and the receiving user information to the DRM interoperablesystem 500 in response to the request (operations S174 and S175). Thetransmission user information and the receiving user information may betransmitted by communicating requests and responses between the DRMinteroperable system 500 and the service providers 420 and 620.

The transmission user information may indicate information on the userof the first client device 410 which transmits the content. In addition,the receiving user information may indicate information on the user ofthe second client device 610 which receives the content. Thetransmission user information and the receiving user informationincludes predetermined information on the user, which is a determinationstandard for applying the content misuse prevention policy, for example,information on an age of the user.

Subsequently, the DRM interoperable system 500 may request apredetermined entity of the first DRM area 400, for example, the firstservice provider 420 to provide content information (operation S176).The first service provider 420 provides the content information inresponse to the request (operation S177). At this time, the contentinformation may include limit information for preventing content misuse.For example, the content information may include information on an agelimit of a user who can use the content.

Next, the DRM interoperable system 500 determines the possibility of thecontent misuse by comparing and analyzing the content information andtransmission and receiving user information (operation S178) and reportsto the first client device 410 whether the content is transmitted to thesecond client device 610 depending on the determination result(operation S179). In addition, the DRM interoperable system 500 mayreport to the second client device 610 whether the content istransmitted. The possibility of content misuse is determined by the DRMinteroperable system 500 or external misuse prevention system.

For example, when the age limit information included in the contentinformation represents that users under the age of 19 are not admittedand when the age of the transmission user is 15, the DRM interoperablesystem 500 determines that it is possible to misuse the requestedcontent, reports a message for representing that the content cannot betransmitted to the first client device 410, and stops the procedure.

On the other hand, when the age of the receiving and transmission useris 24, the DRM interoperable system 500 determines that it is notpossible to misuse the requested content and reports a message forrepresenting that the content is normally to be transmitted to the firstclient device 410. After reporting the normal transmission, the DRMinteroperable system 500 transforms the license information and a dataprotection technique applied to the requested content from the first DRMto the second DRM (operation S180) and transmits the transformationresult to the second client device 610 (operation S181).

The content misuse prevention policy may be determined and accepted byconference or approval of DRM providers (not shown) related to the DRMinteroperable system 500 and the service providers 420 and 620. Inaddition, communication messages among the first DRM area 400, the DRMinteroperable system 500, and the second DRM area 600 may becommunicated in a format of an extensible markup language (XML),hypertext markup language (HTML), or general data. When thecommunication is performed, a security channel with advanced encryptionstandard (AES) 128 bits or more may be provided.

EXAMPLE 5-2

FIG. 44 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-2. FIG. 44 illustrates a procedure of preventing a contentcontaminated by viruses from spreading when a DRM is allowed to becompatible with another DRM.

As shown in FIG. 44, the DRM interoperable system 500 receives a contenttransmission request message for requesting a predetermined content tobe transmitted from the first client device 410 to the second clientdevice 610 (operation S190). The content transmission request messageincludes the content requested to be transmitted. Since the requestedcontent is transmitted from the first client device 410 included in thefirst DRM area 400, the content indicates a content applied with thefirst DRM.

When receiving the content transmission request message, the DRMinteroperable system 500 determines whether the content is contaminatedby analyzing the requested content (operation S192). According to thedetermination result, the DRM interoperable system 500 determineswhether the content is transmitted to the second client device 610 andreports the determination result to the first client device 410(operation S193). At this time, the DRM interoperable system 500 mayalso report the determination result to the second client device 610.

For example, the DRM interoperable system 500 performs a virus check onthe requested content. When the content is contaminated by viruses, theDRM interoperable system 500 determines that the content cannot betransmitted, reports a message for representing determination result tothe first client device 410, and stops the procedure. In this case, thefirst client device 410 or the first service provider 420 can cleanviruses from the content. Subsequently, the first client device 410requests the DRM interoperable system 500 to retransmit the content.

Alternatively, when the requested content is not contaminated by theviruses, the DRM interoperable system 500 determines that the content isto be normally transmitted and reports a message for representing thedetermination result to the first client device 410.

Subsequently, the DRM interoperable system 500 performs DRMtransformation in which license information and a data protectiontechnique applied to the requested content are transformed from thefirst DRM to the second DRM (operation S193) and transmits thetransformation result to the second client device 610 (operation S194).

On the other hand, the DRM interoperable system 500 determines thepossibility of the content contamination. When the content iscontaminated, the DRM interoperable system may clean the viruses fromthe content and normally transmit the content. In this case, the DRMinteroperable system 500 may include a tool or system capable ofcleaning the viruses from the content or request a separate anti-virussystem connected through a network to clean the viruses from thecontent. In addition, specifications on the viruses, which contaminatethe content, and the cleaning result may be reported to the first clientdevice 410.

EXAMPLE 5-3

FIG. 45 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-3. FIG. 45 illustrates an example to which a watermarkingfunction can be applied when a DRM is allowed to be compatible withanother DRM.

As shown in FIG. 45, the DRM interoperable system 500 receives a contenttransmission request message for requesting a predetermined content tobe transmitted from the first client device 410 to the second clientdevice 610 (operation S190). The content transmission request messageincludes the content requested to be transmitted. Since the requestedcontent is transmitted from the first client device 410 included in thefirst DRM area 400, the content indicates a content applied with thefirst DRM.

When receiving the content transmission request message, the DRMinteroperable system 500 determines whether a watermark is inserted intothe content by analyzing the content requested to be transmitted(operation S196). When the watermark is inserted into the content, theDRM interoperable system 500 performs a DRM trans-formation process inwhich license information and a data protection technique applied to therequested content are transformed from the first DRM to the second DRM(operation S201) and transmits the transformation result to the secondclient device 610 (operation S202).

Alternatively, when the watermark is not inserted into the requestedcontent, the DRM interoperable system 500 requests a predeterminedentity of the first DRM area 400, for example, the first serviceprovider 420 to perform a watermarking process (operation S197).Specifically, the watermark is requested to be inserted into the contentrequested to be transmitted. Then, the first service provider 420, whichis requested to perform the watermarking process, inserts the watermarkinto the content requested to be transmitted (operation S198) andrequests the DRM interoperable system 500 to transmit the content again(operation S199).

The DRM interoperable system 500 checks whether the watermark isinserted into the requested content (operation S200), performs the DRMtransformation process in which license information and a dataprotection technique applied to the requested content are transformedfrom the first DRM to the second DRM (operation S201), and transmits thetransformation result to the second client device 610 (operation S202).

On the other hand, when an engine for providing a watermarking functionis installed in the first client device 410, the DRM interoperablesystem 500 may request the first client device 410 to perform thewatermarking process. At this time, the first client device 410 canrequest the first service provider 420 or content provider to providecopyright information for generating the watermark and can obtain thecopyright information.

Up to now, a procedure of inserting the watermark when the DRM isallowed to be compatible with another DRM is described with reference toFIG. 45. In order to embody the procedure illustrated in FIG. 45, awatermarking system for providing the watermarking function has to beincluded in a predetermined entity of the first DRM area 400.Alternatively, when the watermarking system is not included in apre-determined entity of the first DRM area 400, the DRM interoperablesystem 500 may perform the watermarking process or request a separatewatermarking system to perform the watermarking process. These caseswill be described in the following with reference to FIG. 46.

EXAMPLE 5-4

FIG. 46 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-4. FIG. 46 illustrates another example to which a watermarkingfunction can be applied when a DRM is allowed to be compatible withanother DRM.

As shown in FIG. 46, the DRM interoperable system 500 receives a contenttransmission request message for requesting a predetermined content tobe transmitted from the first client device 410 to the second clientdevice 610 (operation S210). The content transmission request messageincludes the content requested to be transmitted. Since the requestedcontent is transmitted from the first client device 410 included in thefirst DRM area 400, the content indicates a content applied with thefirst DRM.

When receiving the content transmission request message, the DRMinteroperable system 500 determines whether a watermark is inserted intothe requested content (operation S211). When the watermark is insertedinto the content, the DRM interoperable system 500 performs a DRMtransformation process in which license information and a dataprotection technique applied to the requested content are transformedfrom the first DRM to the second DRM (operation S215) and transmits thetransformation result to the second client device 610 (operation S216).

Alternatively, when the watermark is not inserted into the requestedcontent, the DRM interoperable system 500 requests a predeterminedentity of the first DRM area 400, for example, the first serviceprovider 420 to provide information on a copyright holder of therequested content (operation S212). Specifically, the information on thecopyright holder may be information on a content provider. In this case,the DRM interoperable system 500 may request the first service provider420 to provide the information on the copyright holder. Alternatively,the DRM interoperable system 500 may directly request the contentprovider to provide the information on the copyright holder. In Example5-4, it is assumed that the information on the copyright holder isprovided by the first service provider 420. However, the presentinvention is not limited thereto.

The first service provider 420 provides the information on the copyrightholder to the DRM interoperable system 500 in response to the requestfor the information on the copyright holder transmitted from the DRMinteroperable system 500 (operation S213). Then, the DRM interoperablesystem 500 generates a watermark by using the information on thecopyright holder provided by the DRM interoperable system 500, decryptsthe content requested to be transmitted, and performs the watermarkingprocess in which the generated watermark is inserted into the content(operation S214). At this time, the DRM interoperable system 500 mayinclude the watermarking system and use the watermarking system.Alternatively, the DRM interoperable system 500 may directly request aseparate watermarking system connected through a network to perform thewatermarking process.

When the watermarking process is completed, the DRM interoperable system500 performs the DRM transformation process (operation S215).Specifically, the license information and the data protection techniqueapplied to the content into which the watermark is inserted aretransformed to the second DRM that is a target DRM. Subsequently, theDRM interoperable system 500 transmits the transformed content to thesecond client device 610 (operation S216).

On the other hand, the DRM interoperable system 500 may enable thewatermarking process to be performed by providing information on theaddress of the separate watermarking system, for example, a URL addressto the first client device 410. In this case, the first client device410 may directly request the first service provider 420 or contentprovider to provide the information on the copyright needed for thewatermarking process. Alternatively, the DRM interoperable system 500may provide the information on the copyright provided by the firstservice provider 420 together with the URL address to the first clientdevice 410. In addition, the DRM interoperable system 500 may enable thewatermarking process to be performed by providing the URL address of theseparate watermarking system to the first service provider 420 of thefirst DRM area 400 or content provider.

EXAMPLE 5-5

FIG. 47 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-5. FIG. 47 illustrates an example to which a fingerprintingfunction can be applied when a DRM is allowed to be compatible withanother DRM.

As shown in FIG. 47, the DRM interoperable system 500 receives a contenttransmission request message for requesting a predetermined content tobe transmitted from the first client device 410 to the second clientdevice 610 (operation S221). The content transmission request messageincludes the content requested to be transmitted. Since the requestedcontent is transmitted from the first client device 410 included in thefirst DRM area 400, the content indicates a content applied with thefirst DRM.

When receiving the content transmission request message, the DRMinteroperable system 500 determines whether a fingerprint including theuser information of the first client device 410 is inserted into thecontent by analyzing the content requested to be transmitted (operationS222). The determination process may be performed immediately after thecontent transmission request is received or before the DRMtrans-formation is performed.

When it is determined that the fingerprint is normally inserted into thecontent, the DRM interoperable system 500 performs the DRMtransformation process in which license information and a dataprotection technique applied to the requested content are transformedfrom the first DRM to the second DRM (operation S227), and transmits thetransformation result to the second client device 610 (operation S228).

Alternatively, when it is determined that the fingerprint is notinserted into the content requested to be transmitted, the DRMinteroperable system 500 requests the first client device 410 to performa fingerprinting process (operation S223). Specifically, the fingerprintincluding the user information of the first client device 410 isrequested to be inserted into the content requested to be transmitted.

At this time, the DRM interoperable system can provide addressinformation needed for providing a fingerprinting engine for performingthe fingerprinting process, for example, a URL to the first clientdevice 410 through a URL trigger or back channel. Since fingerprintingalgorithms are remarkably various, the DRM interoperable system 500 maynot store and manage all the fingerprinting algorithms. Accordingly, theDRM interoperable system 500 has to provide the address of thefingerprinting system which can download the fingerprinting enginehaving an algorithm used in the first DRM area 400 to the first clientdevice 410. The address of the fingerprinting system can be obtained bycommunicating requests and responses between the DRM interoperablesystem 500 and the first service provider 420.

The fingerprinting system may be included in the first service provider420. Alternatively, the fingerprinting system may be a predeterminedserver interacting with the service provider 420. However, when thefingerprinting function is not included in the first DRM area 400, thefirst service provider 420 cannot provide the fingerprinting function.In this case, the DRM interoperable system 500 may provide addressinformation of a separate fingerprinting system capable of providing afingerprinting engine to the first client device. In addition, when apredetermined fingerprinting engine is installed in the first clientdevice 410, the DRM interoperable system 500 may not transmit additionaladdress information and request the first client device 410 to performthe fingerprinting process through the installed fingerprinting engine.

The first client device 410 requested to perform the fingerprintingprocess may perform the fingerprinting process by downloading thefingerprinting engine by using the address information received from theDRM interoperable system 500 or perform the fingerprinting process byusing the installed fingerprinting engine (operation S224).Specifically, the fingerprint including the user information is insertedinto the requested content.

Subsequently, the first client device 410 requests the DRM interoperablesystem 500 to transmit the content into which the fingerprint isinserted to the second client device 610 again (operation S225). Then,the DRM interoperable system 500 checks whether the fingerprint isinserted into the requested content (operation S226), performs the DRMtransformation process in which license information and a dataprotection technique applied to the requested content are transformedfrom the first DRM to the second DRM (operation 227), and transmits thetransformation result to the second client device 610 (operation S228).

On the other hand, although it is not shown, the DRM interoperablesystem 500 may request the second client device 610 that receives thecontent to perform the fingerprinting process. In this case, the DRMinteroperable system 500 may provide the address information of thefingerprinting system capable of performing the fingerprinting processto the second client device 610. At this time, the address informationof the fingerprinting system can be obtained by communicating requestsand responses between the DRM interoperable system 500 and the secondservice provider 610. In addition, when the second service provider 610does not include the fingerprinting function, the DRM interoperablesystem 500 may provide an address of a separate fingerprinting system.

EXAMPLE 5-6

FIG. 48 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-6. FIG. 48 illustrates another example to which afingerprinting function can be applied when a DRM is allowed to becompatible with another DRM. In Example 5-6, the DRM interoperablesystem includes a fingerprinting engine.

As shown in FIG. 48, the DRM interoperable system 500 receives a contenttransmission request message for requesting a predetermined content tobe transmitted from the first client device 410 to the second clientdevice 610 (operation S230). The content transmission request messageincludes the content requested to be transmitted. Since the requestedcontent is transmitted from the first client device 410 included in thefirst DRM area 400, the content indicates a content applied with thefirst DRM. The received content transmission request message includesthe transmission and receiving user information, that is, userinformation of the first and second client devices 410 and 610.

Subsequently, the DRM interoperable system 500 determines whether afingerprint including the user information of the first client device410 is inserted into the content by analyzing the content requested tobe transmitted (operation S231). When the fingerprint is inserted intothe content requested to be transmitted, the DRM interoperable system500 performs the DRM transformation process in which license informationand a data protection technique applied to the requested content aretransformed from the first DRM to the second DRM (operation S233), andtransmits the transformation result to the second client device 610(operation S234).

Alternatively, when the fingerprint is not inserted into the contentrequested to be transmitted, the DRM interoperable system 500 generatesa fingerprint including the received user information of the firstclient device 410 by using the fingerprint engine included in the DRMinteroperable system 500, encrypts the content requested to betransmitted, and performs the fingerprinting process in which thegenerated fingerprint is inserted into the content (operation S232). Thefingerprinting engine is stored in a predetermined device in the DRMinteroperable system 500 in a cache form. The fingerprinting engine canoperate, when the fingerprinting process is performed.

When the fingerprinting process (operation S232) is completed, the DRMinteroperable system 500 performs the DRM transformation process(operation S233).

Specifically, the license information and the data protection techniqueapplied to the content into which the fingerprint is inserted aretransformed to the second DRM that is a target DRM. Subsequently, theDRM interoperable system 500 transmits the transformed content to thesecond client device 610 (operation S234).

On the other hand, the DRM interoperable system 500 may insert thefingerprint including information on the second client device 610 whichreceives the content into the content. In this case, the DRMinteroperable system 500 has to store the corresponding fingerprintingengine in a cache form.

EXAMPLE 5-7

FIG. 49 is a functional block diagram illustrating a method ofprocessing a content by using a DRM interoperable system according toExample 5-7. FIG. 49 illustrates a procedure of reporting to a system,which includes or distributes the content, that fingerprint informationof the content is not matched with the user information, when a user ofwhich finger print information is not matched with the user informationrequests the content to be transmitted.

As shown in FIG. 49, the DRM interoperable system 500 receives a contenttransmission request message for requesting a predetermined content tobe transmitted from the first client device 410 to the second clientdevice 610 (operation S250). The content transmission request messageincludes transmission and receiving user information, that is, userinformation of the first and second client device 410 and 610. Inaddition, a fingerprint is inserted into the content requested to betransmitted.

The DRM interoperable system 500 compares and analyzes the userinformation included in the fingerprint information inserted into thecontent requested to be transmitted and the user information of thefirst client device 410 (operation S251). When finding an error in whichthe user information included in the fingerprint is not matched with theuser information of the first client device 410 (operation S252), theDRM interoperable system 500 reports to the first client device that theerror occurs (operation S254). In addition, the DRM interoperable system500 transmits disapproval for representing that the share of the contentis not approved to the second client device 610 (operation S253).Accordingly, an illegal content of which fingerprint is not matched withthe user information of the first client device 410 cannot betransmitted.

While the present invention has been particularly shown and describedwith reference to exemplary embodiments thereof, it will be understoodby those skilled in the art that various changes in form and details maybe made therein without departing from the spirit and scope of thepresent invention as defined by the appended claims.

As described above, it is possible to provide various transmission typesof data in a DRM interoperable system according to an embodiment of thepresent invention. Specifically, it is possible to effectively transmitdata by constructing multi-chains so as to transmit the data to one ormore destinations. In addition, a transmission status of the datatransmitted through each chain may be provided as an event message.

1.-16. (canceled)
 17. A computer-implemented method comprising:receiving a transmission request message for requesting data comprisingat least one content or at least one license to be transmitted to adestination; querying entities for capability information associatedwith each entity; receiving the capability information; accessingcapability data describing a capability of source, intermediate anddestination devices, and a Digital Rights Management (DRM) system, usingthe received capability information; forming chains that each include atleast two entities, based on the accessed information; and transmittingthe data to the destination using the chains.
 18. The method of claim17, wherein the at least two entities forming the chains, comprise: anexporter configured to: export the data from a source, and transmit theexported data; a transformer configured to: transform the transmitted,exported data into a data format supported by a destination, transmitthe transformed data; and an importer configured to: receive thetransmitted, transformed data, and transmit the received data to thedestination.
 19. The method of claim 17, wherein the at least twoentities forming the chains, comprises: an exporter configured to:export the data from a source, and transmit the exported data; and animporter configured to: receive the transmitted, exported data, andtransmit the received data to a destination.
 20. The method of claim 17,wherein transmitting the data further comprises: forming a primary chainincluding an exporter and a transformer; transmitting the data from theexporter to the transformer using the primary chain; forming at leastone secondary chain including the transformer and an importer; andtransmitting the data from the transformer to the importer using the atleast one secondary chain.
 21. A device comprising: an interfaceconfigured to: receive a transmission request message for requestingdata comprising at least one content or at least one license to betransmitted to a destination, receive capability information, andtransmit data to the destination using formed chains; and a processorconfigured to: query entities for the capability information associatedwith each entity, access capability data describing a capability ofsource, intermediate and destination devices, and a Digital RightsManagement (DRM) system, using the received capability information, andform the chains that each include at least two entities, based on theaccessed information.
 22. The device of claim 21, wherein the at leasttwo entities forming the chains, comprise: an exporter configured to:export the data from a source, and transmit the exported data; atransformer configured to: transform the transmitted, exported data intoa data format supported by a destination, transmit the transformed data;and an importer configured to: receive the transmitted, transformeddata, and transmit the received data to the destination.
 23. The deviceof claim 21, wherein the at least two entities forming the chains,comprises: an exporter configured to: export the data from a source, andtransmit the exported data; and an importer configured to: receive thetransmitted, exported data, and transmit the received data to adestination.
 24. The device of claim 21, wherein transmitting the datafurther comprises: forming a primary chain including an exporter and atransformer; transmitting the data from the exporter to the transformerusing the primary chain; forming at least one secondary chain includingthe transformer and an importer; and transmitting the data from thetransformer to the importer using the at least one secondary chain. 25.A system comprising: one or more computers; and a computer-readablemedium coupled to the one or more computers having instructions storedthereon which, when executed by the one or more computers, causes theone or more computers to perform operations comprising: receiving atransmission request message for requesting data comprising at least onecontent or at least one license to be transmitted to a destination,querying entities for capability information associated with eachentity, receiving the capability information, accessing capability datadescribing a capability of source, intermediate and destination devices,and a Digital Rights Management (DRM) system, using the receivedcapability information, forming chains that each include at least twoentities, based on the accessed information, and transmitting the datato the destination using the chains.
 26. The system of claim 25, whereinthe at least two entities forming the chains, comprise: an exporterconfigured to: export the data from a source, and transmit the exporteddata; a transformer configured to: transform the transmitted, exporteddata into a data format supported by a destination, transmit thetransformed data; and an importer configured to: receive thetransmitted, transformed data, and transmit the received data to thedestination.
 27. The system of claim 25, wherein the at least twoentities forming the chains, comprises: an exporter configured to:export the data from a source, and transmit the exported data; and animporter configured to: receive the transmitted, exported data, andtransmit the received data to a destination.
 28. The system of claim 25,wherein transmitting the data further comprises: forming a primary chainincluding an exporter and a transformer; transmitting the data from theexporter to the transformer using the primary chain; forming at leastone secondary chain including the transformer and an importer; andtransmitting the data from the transformer to the importer using the atleast one secondary chain.